Here are things that should be done whenever a release is prepared:
Positive build reports for each supported platform - although it is arguably less necessary for a comprehensive list if we are releasing a minor upgrade
Some kind of Standard Test Plan
Binary RPM packages
If the release is a ".0" one, we need to open a new STABLE branch
cvs tag -b REL_1_2_STABLE
Tag the with the release ID. For version 1.1.2, this would be REL_1_1_2
cvs tag REL_1_1_2
Check out a copy via cvs export -rREL_1_1_2
Run autoconf so as to regenerate configure from configure.ac
Purge directory autom4te.cache so it is not included in the build
Purge out .cvsignore files; this can be done with the command find . -name .cvsignore | xargs rm
Run tools/release_checklist.sh
This does a bunch of consistency checks to make sure that various files that are supposed to contain version numbers contain consistent values.
For instance, configure should contain, for release 1.1.2:
PACKAGE_VERSION=REL_1_1_2
PACKAGE_STRING=postgresql-slony1-engine REL_1_1_2
config.h.in needs to contain the version number in two forms; the definitions for SLONY_I_VERSION_STRING and SLONY_I_VERSION_STRING_DEC both need to be updated.
src/backend/slony1_funcs.sql has
major/minor/patch versions in functions
slonyVersionMajor(),
slonyVersionMinor(), and
slonyVersionPatchlevel(). These need to be
assigned "by hand" at this point.
It sure would be nice if more of these could be assigned automatically, somehow.
Don't commit the new configure; we shouldn't be tracking this in CVS.
make sure that the generated files from .l and .y are created, for example slony/conf-file.[ch]
Currently this is best done by issuing ./configure && make all && make clean but that is a somewhat ugly approach.
Make sure that generated Makefiles and such from the previous step(s) are removed.
make distclean ought to do that...
Generate HTML tarball, and RTF/PDF, if possible... Note that the HTML version should include *.html (duh!), *.jpg, *.png, as well as *.css
Run make clean in doc/adminguide before generating the tarball in order that bookindex.sgml is NOT part of the tarball
Alternatively, delete doc/adminguide/bookindex.sgml
Rename the directory (e.g. - slony1-engine) to a name based on the release, e.g. - slony1-1.1.2
Generate a tarball - tar tfvj slony1-1.1.2.tar.bz2 slony1-1.1.2
Build the administrative documentation, and build a tarball as slony1-1.1.2-html.tar.bz2
Make sure that the docs are inside a subdir in the tarball.
Put these tarballs in a temporary area, and notify everyone that they should test them out ASAP based on the Standard Test Plan.