Revision 1 as of 2009-08-07 21:33:01

Clear message

DRAFT - This is a work in progress

Preparing a release is a fairly straight-forward process despite appearances to the contrary.

Are you ready?

Before you start make sure all bugs in the current active milestone on Launchpad are in the 'Fix Committed' state. It's also a good idea to review the Bazaar log to make sure the NEWS file contains information about all the important changes. When all the bug fixes and new features are ready in trunk it's time to create the release.

Preparing release-candidate packages

The python-storm package is made to be built with AutoPPA. You need to create a ~/.autoppa.conf file with contents similar to:

email = Username <>
ppa = username
branch = /home/username/src/projects/storm/trunk
repository = /home/username/src/autoppa-builds
releases = dapper hardy intrepid jaunty karmic

You'll also need something similar to this in your ~/

fqdn =
method = ftp
incoming = ~username/ppa/ubuntu/
login = anonymous
allow_unsigned_uploads = 0

Build the package in your own PPA so that you can test them before publishing them. Use the --no-merge option to build test packages:

$ autoppa --no-merge storm-0.15-1~rc2

FIXME Provide instructions explaining AutoPPA installation.

This will upload sources to your PPA for the Ubuntu releases specified in ~/.autoppa.conf. When the python-storm` packages build you should test them in pristine environments, to make sure they work properly. If you run into problems you can build the package locally to debug issues:

$ fakeroot debian/rules binary

If any changes had to be made to the package to get the new version to build they should be landed in a separate branch that is merged to trunk.

Preparing a release-candidate tarball

$ ./ sdist --formats bztar

Creating the final release packages and tarball

When the package is perfect and ready for redistribution rebuild it with the release version:

$ autoppa storm-0.15-1~storm1

This will upload sources, like before, but it will also create a branch with a revision storing the changes made for each release being built. This branch will be merged to trunk and a tag based on the package version will be added to the new revision to track it.