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