MakingARelease

Here's what I do when putting out a new release:

• Tell people with SVN commit access to stop making commits to trunk for a while.
• Run a make indent and commit.
• Bump the version numbers and release dates in Makefile.in, Patchevel, hdrs/version.h, CHANGES.184, HACKING.184, run make versions and commit.
• Create a new release candidate tag: svn copy https://pennmush.googlecode.com/svn/trunk https://pennmush.googlecode.com/svn/tags/184pXXrcN -m "PennMUSH 1.8.4pXX release candidate N".
• Wait a few days, getting people to test it and fix any last-minute bugs.
• Possibly repeat the above steps a few times.
• Do a final updating of release dates in the files if the date has slipped, a last make versions so the date's in HELP CHANGES, and commit.
• Tag the release: svn copy https://pennmush.googlecode.com/svn/trunk https://pennmush.googlecode.com/svn/tags/184pXX -m "PennMUSH 1.8.4pXX Release".
• Check out a clean copy: svn export http://pennmush.googlecode.com/svn/tags/184pXX pennmush-1.8.4pXX.
• Create gzipped and pbzip2'ed tarballs from this copy.
• Create a patch: svn diff --diff-cmd=diff -x '-uNd --speed-large-files' http://pennmush.googlecode.com/svn/tags/184pYY http://pennmush.googlecode.com/svn/tags/184pXX > 1.8.4-patchXX.
• Append patch instructions (Bumping version as needed), changelog, and the results of running diffstat on the patchfile.
• If it's a big file, create a compressed version of the patch.
• Create a readme file using the standard template, bumping version numbers as needed.
• Create checksums of the tarballs and patchfile(s): openssl dgst -sha1 pennmush-1.8.4pXX.tar.gz ... > pennmush-1.8.4pXX.checksums
• Upload the files to the download server and the googlecode project. On the googlecode download page, remove the featured tags on the old release and make sure they're on the new one.