Release Checklist

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

• If the release modified the set of version-specific SQL files in src/backend (e.g. - it added a new slony1_base.v83.sql or slony1_funcs.v83.sql), or if we have other changes to the shape of PostgreSQL version support, the function load_slony_functions() in src/slonik/slonik.c needs to be revised to reflect the new shape of things.

• The new release needs to be added to function upgradeSchema(text) in src/backend/slony1_funcs.sql.

  This takes place in a "cross-branch" fashion; if we add version 1.1.9, in the 1.1 branch, then version 1.1.9 needs to be added to the 1.2 branch as well as to later branches (e.g. - 1.3, 1.4, HEAD). Earlier branches will normally not need to be made aware of versions added to later branches...

• 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 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.