Prepare for the Release
- create a release entry on SF. (This can be used to stage pre-release builds and release candidates.)
- update documentation/download.html with the release number, link to the release entry, and an empty release date.
Release
- bump the release number in RELEASENOTES.txt, build.properties, and project.xml (e.g. from 2.2.2-dev to 2.2.2)
- update the docs/download.html with the release date and highlights of the release.
- commit
- create a tag in subversion (svn copy...see Tags)
- bump release number again (e.g. from 2.2.2 to 2.2.3-dev) and commit
- pull (svn checkout or switch) from tag
- build the release on Windows with earliest supported JDK. Using Windows is required for windows installer distribution, and you use the earliest supported JDK (currently 1.5) so that the maximum number of people can use the binary release.
- deploy the release in SF & use the notify functionality
- limit the release notes to only the info for that release
- check the "Preserve my pre-formatted text." box for the release notes
- upload the new documentation on SF (ensure that cruisecontrol group has write permission)
- in Jira mark the release finished; create next release if needed.
Post Announcements
- announce release on cc-announce, cc-user and cc-devel mailing lists
list of places the announcement was sent to in the past
list of places the announcement could/should be sent to
|
|
Would like to look at automating most if not all these steps, including removing duplication between different release packages (i.e., binary vs source releases)
I'm tempted to delete the AllReleases table. I don't think it is worth the maintence cost.
That seems fine to me. Now that I think about it, I'm not really sure it serves a valuable purpose. It's more for historical curiosity.
AllReleases table gone. I've moved the most relevant information into the download.html.