Release Checklist

Slony-I 2.2.10 Documentation
Prev | Fast Backward | Chapter 7. Appendix | Fast Forward | Next

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

Prev | Home | Next
Appendix | Up | Using Slonik