Chapter B3
Release procedure

In the beta release cycle, Cactus is maintained in two CVS repositories - the ‘stable’ /cactus and the development /cactusdevcvs. The stable version is the last beta release and no commits should ever be made to it - it is for people who do not want to worry about things breaking from day to day. The development version is the tree used for developing the next beta release.

Making a beta release consists of copying the cvs modules from the development repository to the stable repository. The following procedure is used:

Notify committers of start of release procedure

This ensures that no commits are made during the following procedure. If it is impossible, for some reason, to notify a person of the start of the procedure, that person’s commit rights should be revoked during the procedure to prevent accidents.

Check the code on all supported architectures

The code should be checked out (in a fresh place), compiled and the test-suites run on all suppported architectures. Problems found should be fixed or noted in the release notes. This is an iterative procedure, as any commits made to fix problems need to be checked on all other architectures.

Check example parameter files

The example parameter files in thorn par directories should be run and updated for any additional or changed thorns or parameters.

Update ReleaseNotes

The release notes should be added to the doc/ReleaseNotes file.

Tag the code

Tag the code with the latest release tag and update the LATEST and STABLE tags. The easiest way to do this is from a clean checkout.

cvs -d:pserver:<...>@cvs.cactuscode.org:/cactusdevcvs co Cactus  
cd /Cactus  
make checkout  
cvs tag Cactus_4_0_Beta_X  
cvs tag -F LATEST  
cvs tag -F STABLE

Log into cvs machine as cactus_admin

All repository maintanence should be done as the cactus admin user.

Store old module files

A directory should be made in the stable repository, and all releaseable modules should be moved into that directory. This will temporarily break checkouts/updates from that repository. A suggested command is of the form

cd /cactus  
mkdir 4.0/betaX  
mv Cactus{,Base,Bench,Connect,Einstein,Elliptic,Examples,...} betaX

Copy new module files

e.g.

cp -r /cactusdevcvs/Cactus{,Base,Connect,Einstein,X,X,X} .

Fix permissions on new module files

find Cactus{,Base,Connect,Einstein,X,X,X} -type d -exec chmod 777 {} \;  
export CVSROOT=/cactus  
Setperms.pl public Cactus{,Base,Connect,Einstein,X,X,X}

Update CVS modules file for new modules

The stable repository’s modules file should be updated with any new module information added.

Check that checkout/update works

A fresh checkout should be made as a double check that all permissions have been set correctly.

Update version of development tree

Update the version in Makefile and commit it to the development tree.

Re-enable commit access

People whose commit access was removed in the first part of this procedure should have access re-enabled.

Notify people

The relase notes should be sent out to the cactus mailing lists and any other relevant places such as linux-announce and Freshmeat.

Update web page

The release should be noted in the news section of the web page. Most information such as generating documentation takes place automatically for the web pages, the only thing which needs to be done manually is to checkout any new arrangements in the Stable Release in the relevent directories in the CheckOut directory as cactus_web.

Close PRs

Any problem reports which were closed in the beta relase should be audited for correct entries in the Fix field and then their state should be marked as closed.