Slony-I 1.2.0 Documentation | ||||
---|---|---|---|---|
Prev | Fast Backward | Fast Forward | Next |
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
Tag with the release ID. For version 1.1.2, this would be 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
Need to make sure that all references to CVS tags properly point to the tag for the release.
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
RPM spec files used to contain release tags as well as names of tarballs which needed to be updated. As of 2005-12-13, there is less of this... For those platforms with specific spec files such as SuSE, some editing still needs to be done. see the file(s) in the suse dir for more information
The admin guide version.sgml file needs to contain the release name. This should not need to be touched; version.sgml is generated automatically with the release name/tag on demand.
It sure would be nice if more of these could be assigned automatically, somehow.
commit the new configure
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.
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 (on some mailing list???) that they should test them out ASAP based on the Standard Test Plan.