changes to the release process

[Ryan Culpepper]

1) The release catalog will live in a separate repository
(github:racket/release-catalog) rather than included as a directory on
the main repository. The reason is that the main repository holds some
of the core packages, and so checking in an updated catalog to the
main repo makes those package checksums change, which means that the
catalog should be updated, and so on.

2) Release branches will be created only when needed. For a given pkg,
the code that gets release is determined by these rules:

- If there is a release branch, it's the contents of the release
branch (when the repo is polled for a build).
- Otherwise, it's the SNAPSHOT of the master branch when the release
catalog was created (which I'll call "branch day"). It does NOT
track later updates to the master branch.

This is possible because the release catalog contains not only a
source (repo and branch) but also a checksum, which for git repos is
interpreted as a specific commit to fetch. I will poll for release
branches periodically (and right before builds) to update the release
catalog.

One upside is the creation of fewer release branches (and no more
massive deluges of email notifications).

The downside is that it can be hard to remember what the state of
master on branch-day was, and it's not trivial to get that
information, but it should be partly offset that issue with support
scripts (not yet available).

Changes for pkg repo managers:

If a new commit (after the branch-day snapshot) should be included in
the release, you must first create a release branch.

To create the release branch as a copy of the current master branch:

- git pull # make sure you're up to date!
- git checkout -b release master
- git push origin release

To create the release branch as a copy of the branch-day master
snapshot:

- let $COMMIT be the checksum of the pkg in the release-catalog
(I'll write a script to help find this information)
- git pull # make sure you're up to date!
- git checkout -b release $COMMIT
- git push origin release

Then fast-forward or cherry-pick as usual.

At the end of the release, I will create version tags from the release
branches (to prevent their commits from being GC'd) and delete the
release branch.

Changes for other developers: None.

Ryan