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

  Does not need to be done by hand - the later make distclean step does this for you.

• Purge out .cvsignore files; this can be done with the command find . -name .cvsignore | xargs rm

  Does not need to be done by hand - the later make distclean step does this for you.

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

  Slightly better may be ./configure && make src/slon/conf-file.c src/slonik/parser.c src/slonik/scan.c

• Make sure that generated Makefiles and such from the previous step(s) are removed.

  make distclean will do that...

  Note that make distclean also clears out .cvsignore files and autom4te.cache, thus obsoleting some former steps that suggested that it was needful to delete them.

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