Swarm: release checklist

Wiki main page
Swarm main page
Software main page
Stable release
Development snapshot
License
Platforms
Prior releases
Documentation main page
Doc set & reference guide
User guide
FAQ
User support email list
Applications & contrib code
Applications
User-contributed code
Release Management
Checklist

SVN Repository Tasks

One of the primary features of using a source code repository is its ability to support software releases and maintain identity of a specific release. Branching allows the release to be worked on concurrently with development for the next release as well as bug fixing independent of the main development; while tagging allows historical access to the exact files in a release. The repository tasks are slightly different for a bug fix release versus a release with new functionality.

SVN Repository Tasks for New Functionality Release

Checkout Swarm from the repository. You can use an existing checkout but make sure you don't have any modified files, etc. Safer to just start from a clean checkout. You need the trunk directory and the top-level branches directory.


 svn checkout svn+ssh://user@svn.savannah.nongnu.org/swarm/trunk


 svn checkout -N svn+ssh://user@svn.savannah.nongnu.org/swarm/branches

Update the version number in the VERSION file in trunk and commit to the repository; don't forget to add a ChangeLog entry.

Make a branch for the release by copying trunk to a directory in branches and commit the new branch.


 svn copy trunk branches/Swarm-X_Y


 svn commit -m "X.Y release branch"

Now do all release work in the branch. Any modifications to scripts, files, etc. are done in the branch. Those changes will be merged back to the main development branch later. Update these files in the branch.

configure.in: new version number
NEWS: new version number, bullet items about what is in the new release.
README: new version number
VERSION: new version number

SVN Repository Tasks for Bug Fix Release

Currently bug fix releases should be rare as we don't have a large user and developer community. Consider whether waiting for the next new functionality release is sufficient. A bug fix release do not involve creating a new branch. Instead work in the appropriate branch directory, code and test the bug fixes there.

Work within the release branch.


 svn checkout svn+ssh://user@svn.savannah.nongnu.org/swarm/branches/Swarm-X_Y

Update the version number (increment Z) in the VERSION file commit to the repository; don't forget to add a ChangeLog entry.

Apply bug fixes and commit to the repository; don't forget to add a ChangeLog entries.

Follow the file distribution tasks for a normal release.

Distribution File Tasks

When creating distribution files, we want to eliminate all of the extra files and directories that exist in a repository checkout; we do this by using the export command to get a local copy of the release files.

Create the Source Code Release (Swarm)

Export the source code from the release branch, make sure to use the correct Z value for the bug version number.


 svn export svn+ssh://user@svn.savannah.nongnu.org/swarm/branches/Swarm-X_Y/swarm swarm-X.Y.Z

Generate the configuration files by running autogen.sh

Remove the following files:
- HACKING

Archive the exported code directory, that's the source code release!


 tar zcvf swarm-X.Y.Z.tar.gz swarm-X.Y.Z

Test the source code release by extracting the files into a new directory, preferable on a clean machine, and verify that you can compile and install.

Create the Source Code Release (Swarm Applications)

Export the source code from the release branch, make sure to use the correct Z value for the bug version number.


 svn export svn+ssh://user@svn.savannah.nongnu.org/swarm/branches/Swarm-X_Y/apps swarmapps-X.Y.Z

Archive the exported code directory, that's the source code release!


 tar zcvf swarmapps-X.Y.Z.tar.gz swarmapps-X.Y.Z

Test the source code release by extracting the files into a new directory, preferable on a clean machine, and verify that you can compile and run the applications.

Create the Binary Release

Tag the Release in the SVN Repository

Checkout Swarm from the repository. You can use an existing checkout but make sure you don't have any modified files, etc. Safer to just start from a clean checkout. You need the release branch directory and the top-level tags directory.


 svn checkout svn+ssh://user@svn.savannah.nongnu.org/swarm/branches/Swarm-X_Y branches/Swarm-X_Y


 svn checkout -N svn+ssh://user@svn.savannah.nongnu.org/swarm/tags

Tag the release by copying the release branch to the tags directory with the full version number, and commit the tag.


 svn copy branches/Swarm-X_Y tags/Swarm-X_Y_Z


 cd tags


 svn commit -m "X.Y.Z release tag"

Move the Release Files to the Download Directory

The distribution files now get put on swarm.org.

Transfer swarm-X.Y.Z.tar.gz and swarmapps-X.Y.Z.tar.gz to ftp.swarm.org using the swarm account and sftp to miele.cscs.lsa.umich.edu. Put files in the /data/ftpanon/pub/swarm/src/swarm directory.
Use a brower and connect to http://ftp.swarm.org and verify you can download the file.

Announcement Tasks

Merge Release Changes to the Main Development Branch

After either a new functionality release or a bug fix release, any changes made in the release branch should be merged back to the main development branch. With SVN version 1.5 or later, a simpler merge procedure is possible, but currently Savannah is on an older version, so we show the older merge procedure.

Create a clean checkout of the main development branch.


 svn checkout svn+ssh://user@svn.savannah.nongnu.org/swarm/trunk

Merge the release branch into local working copy that was just created.


 svn merge svn+ssh://user@svn.savannah.nongnu.org/swarm/trunk svn+ssh://user@svn.savannah.nongnu.org/swarm/Swarm-X_Y trunk

Verify the changes and resolve any conflicts. It is also worthwhile to compile and test if there are conflicts.

Lastly commit the changes.


 svn commit -m "merge changes from X.Y release branch"