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

  This was not true for version 2 - version 2.0 was different enough from earlier versions that we rejected having a direct upgrade from 1.x to 2.0, so there are no versions in 1.x branches in upgradeSchema(text) for Slony-I version 2.0.

• Binary RPM packages

• If the release is a ".0" one, we need to open a new STABLE branch

  git checkout HEAD

  git checkout -b REL_3_0_STABLE

• Tag with the release ID. For version 1.1.2, this would be REL_1_1_2

  git tag -a REL_1_1_2

• Check out an exported copy via: git archive REL_1_1_2 -o /tmp/slony1-engine-1.0.2.tar

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

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

• 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 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, and *.css

  Note that, if starting from a "clean" copy of the documentation, in order to properly build the HTML tarball, it is necessary to run make html twice, in order for the document index to be properly constructed.

  • The first time make html is run, the file HTML.index does not yet exist.

    When jade is run, against the document, a side-effect is to generate HTML.index, extracting all index tags from the Slony-I documentation.

  • The second time make html is run, HTML.index is transformed into bookindex.sgml, which jade may then use to generate a nice index page indicating all the index entries included in the documentation tree.

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