Before initiating a release, its assumed that the current HEAD or BRANCH version has been run through the integration self test, that all unit tests pass, that the embryonic test plan has been exercised, and that general usage shows HEAD -- or BRANCH -- to be release worthy.
Send a mail to the list to freeze commits until the all-clear is given.
Up the project.xml 'currentVersion' element value (See Version and Release Numbering for guidance on what version number to use)
Update releasenotes.xml bugs and RFEs closed since last release (Looking at source code history to figure what's changed is too hard; All major changes should have associated BUG and RFE).
Add news of the new release to the site main home page.
Generate the site. Review all documentation making sure it remains applicable. Fix at least the embarrassing. Make issues to have all that remains addressed.
Update the README.txt (We used to include in README text-only version of dependencies list, release notes including items fixed but now we just point to the pertintent html).
Commit all changes made above all in the one commit with a log message about new release. Commit files with the new version, the README.txt, home page, and all changes in documentation including the changelog additions.
Wait on a cruisecontrol successful build of all just committed. Download the src and binary latest builds from under the cruisecontrol 'build artifacts' link.
Build the cruisecontrol produced src distribution version.
Run both the binary and src-built product through the integration self test suite: % $HERITRIX_HOME/bin/heritrix --selftest
Tag the repository. If a bugfix release -- an increase in the least significant digits -- then tag the release. Otherwise, if a major or minor release make a branch (See Appendix B, Version and Release Numbering for more on release versioning). Tags should be named for the release name as in if the release is 1.10.2, then the tag should be heritrix-1_10_2 (You can't use dots in tag names). If a branch, then name the branch for the minor (or major) version name as in, if making a release 1.10.0, then name the branch heritrix-1_10 and if making 2.0.0, name the branch heritrix-2.
Update the project.xml 'currentVersion' and build.xml 'version' property to both be a version number beyond that of the release currently being made (If we're releasing 0.2.0, then increment to 0.3.0).
Login and upload the maven 'dist' product to sourceforge into the admin->File releases section.
Send announcement to mailinglist -- and give an all-clear that commits may resume -- and update our release state on freshmeat site (Here is the URL I used creating our freshmeat project: http://freshmeat.net/add-project/all-done/43820/46804/ -- 46804 is our project ID).