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.