Release Process

Release Process

This page describes the release process in some detail. Getting a release out of the door without embarrassing oversights requires a bit more planning and care than one would like.

Long-term planning

A few months or weeks before the release:

• Decide it is time to make another release
• Choose features which are going to be included, and those which won't be included
• Choose a tentative date
• Begin discussions on the mailing list, reminding people to look at test cases, review patches etc.

One or two weeks before the release

• Set up a wiki planning page for the release
• Ask for volunteers, assign tasks to people
• Review thorns for code quality, documentation, test cases
• Decide on a thorn list
• Decide on a list of release-critical systems
• Collect list of new features, newsworthy items, and acknowledgements for release announcement on wiki
• Choose a concrete date
• Announce date publicly

One or two days before the release

• Have a telecon with the release team, discuss (and modify if necessary) release process and responsibilities
• Get a list of all repositories that are involved (including repositories for tools such as GetComponents)
• Publicly declare a freeze on all involved thorns and tools
• Test all thorns on all systems, collect status reports on wiki
• Update release planning wiki page with peoples', thorns', and systems' statuses
• Set up a (smaller) technical release team who will be available all day on the day of the release
• Draft release announcement

The release

• Have the technical release team meet in the same room (brick, EVO, chat, phone)
• Briefly re-check status of thorns and machines
• Possible disable all outside write access to all critical repositories
• CREATE THE RELEASE BRANCH
• * cvs: ???
• * svn: ???
• * darcs: clone the repository, appending a suffix to the name
• * git: see http://www.zorched.net/2008/04/14/start-a-new-branch-on-your-remote-git-repository/
• * hg: ???
• Possibly update version numbers in stable/development branches
• Update component lists to point to new stable version
• Check out release branch on all systems, re-run all quick tests
• Update documentation on web sites (set up fresh copies of pdfs/htmls)
• Update tutorials on web sites (update version numbers, urls)
• Re-enable write access to all repositories
• Finalise release announcement
• ANNOUNCE

After the release

• Watch mailing lists for problem reports
• Use released version to repeat a few production simulations