Since our release tools don't currently handle the creation of release
candidates, here's what I'm proposing as our general release process
(starting with 0.14) that should let us use the X.Y.0 releases as the
equivalent of a release candidate:
1. When we have all the bugs targeted at the milestone at VERIFIED, and
the release notes have been drafted, we create the release branch and
the release RPMs for that release (e.g. 0.14.0). These all get uploaded
to the client-testing and server-testing repos, and we push the updated
docs to the website (including the new docs branch, e.g. docs-release-0.14)
2. We announce here that the new release is available in the testing
repo, referring to the release notes on the release-specific docs branch.
3. If our own acceptance testing (or anyone else's) finds a showstopper
bug, then we create a maintenance release (e.g. 0.14.1) to fix it and
upload that to the testing repos.
4. If everything looks good, then we move the RPMs over to the main
repos, merge the release branch to master and update the site.
5. Finally, we announce the release here, referring to the release notes
on the main part of the site.
6. Perform additional site cleanup, including updating the technical
road map and design proposal status.
This does have one consequence for changes to client components in
particular: since users drawing directly from our repos may see our
client updates before their local Beaker installation is updated, we
should be conservative in the way we make changes to the way the client
talks to the server over XML-RPC.
Red Hat Infrastructure Engineering & Development, Brisbane
Testing Solutions Team Lead
Beaker Development Lead (http://beaker-project.org/