Differences between revisions 1 and 9 (spanning 8 versions)
Revision 1 as of 2009-08-07 21:33:01
Size: 2520
Editor: jkakar
Comment: Initial notes, still incomplete this is a work in progress
Revision 9 as of 2009-08-08 05:54:36
Size: 3972
Editor: jkakar
Comment:
Deletions are marked like this. Additions are marked like this.
Line 1: Line 1:
`DRAFT - This is a work in progress`
Line 6: Line 4:
<<TableOfContents>>
Line 7: Line 6:
== Are you ready? ==
Line 9: Line 7:
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
[[https://code.launchpad.net/~storm/storm/trunk|trunk]] it's time to
create the release.
== Setting up the tools ==
Line 17: Line 9:
== 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:
The `python-storm` package is made to be built with AutoPPA.  You
need to create a `~/.autoppa.conf` file with contents similar to:
Line 32: Line 21:
You'll also need something similar to this in your ```~/.dput.cf```: You'll also need something similar to this in your `~/.dput.cf`:
Line 43: Line 32:
[[https://launchpad.net/autoppa|AutoPPA]] is available from Launchpad.


== 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 and make sure the NEWS file contains
information about all the important changes. When all the bug fixes
and new features are ready in
[[https://code.launchpad.net/~storm/storm/trunk|trunk]] it's time to
create the release.

Make a `version-0.16` branch where you will implement and test the
modifications required to make the new release. Start by ensuring
`storm/__init__.py` has the new version number set on the `version`
attribute.


== Preparing release-candidate packages ==
Line 44: Line 54:
publishing them. Use the ```--no-merge``` option to build test publishing them. Use the `--no-merge` option to build test
Line 48: Line 58:
$ autoppa --no-merge storm-0.15-1~rc2 $ autoppa --no-merge storm-0.16-1~rc1
Line 51: Line 61:
``FIXME`` Provide instructions explaining AutoPPA installation.
Line 54: Line 62:
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:
specified in `~/.autoppa.conf`. When the `python-storm` packages
build you should test them in pristine environments, to make sure
they work properly. Amazon's EC2 is good for this kind of testing.
If you run into problems you can build the package locally to debug
issues:
Line 63: Line 72:
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.
Commit any changes needed to make the package work to the
`version-0.16` branch.
Line 70: Line 78:
The `release` make target creates a tarball in the `dist`
directory.
Line 71: Line 82:
$ ./setup.py sdist --formats bztar $ make release
Line 74: Line 85:
This will create `dist/storm-0.16.tar.bz2`. Unpack it and make sure
everything is in place: the README, NEWS, TODO and LICENSE files,
the PKG-INFO and other distutils setup files, the debian directory
with package source, the storm and tests directories with Python
code, the Makefile and the storm.egg-info directory.
Line 75: Line 91:
== Creating the final release packages and tarball ==
Line 77: Line 92:
When the package is perfect and ready for redistribution rebuild it
with the release version:
== Creating and publishing the new tarball and packages ==

If the tarball and package are in order merge the branch to trunk.
Use your PPA to rebuild the package, using trunk as the source
branch, with the new release version:
Line 81: Line 99:
$ autoppa storm-0.15-1~storm1 $ autoppa storm-0.16-1~storm1
Line 86: Line 104:
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.
that was built. This branch will be merged to trunk and a tag based
on the new version will be added to the new revision to track it.

When the new packages have finished building find them in your PPA
and copy them to the Storm Team PPA to publish them. Upload the
tarball to Launchpad using the 'Create a release' function from the
milestone page. Write a nice release announcement for the Launchpad
page and send a copy of it to the Storm mailing list to announce the
release. Let Launchpad close the milestone as part of making the
release. After the release is created use the 'Add file' function
to upload the tarball. Be sure to also upload a valid GPG signature
for it.


== Prepare to develop the next version ==

If it hasn't already been done, create a milestone for the next
version and target bugs that needs to be delivered with it. Bump
the `version` value in the `storm/__init__.py`.

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

Setting up the tools

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

[storm]
email = Username <username@example.com>
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 ~/.dput.cf:

[username]
fqdn = ppa.launchpad.net
method = ftp
incoming = ~username/ppa/ubuntu/
login = anonymous
allow_unsigned_uploads = 0

AutoPPA is available from Launchpad.

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

Make a version-0.16 branch where you will implement and test the modifications required to make the new release. Start by ensuring storm/__init__.py has the new version number set on the version attribute.

Preparing release-candidate packages

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.16-1~rc1

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. Amazon's EC2 is good for this kind of testing. If you run into problems you can build the package locally to debug issues:

$ fakeroot debian/rules binary

Commit any changes needed to make the package work to the version-0.16 branch.

Preparing a release-candidate tarball

The release make target creates a tarball in the dist directory.

$ make release

This will create dist/storm-0.16.tar.bz2. Unpack it and make sure everything is in place: the README, NEWS, TODO and LICENSE files, the PKG-INFO and other distutils setup files, the debian directory with package source, the storm and tests directories with Python code, the Makefile and the storm.egg-info directory.

Creating and publishing the new tarball and packages

If the tarball and package are in order merge the branch to trunk. Use your PPA to rebuild the package, using trunk as the source branch, with the new release version:

$ autoppa storm-0.16-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 that was built. This branch will be merged to trunk and a tag based on the new version will be added to the new revision to track it.

When the new packages have finished building find them in your PPA and copy them to the Storm Team PPA to publish them. Upload the tarball to Launchpad using the 'Create a release' function from the milestone page. Write a nice release announcement for the Launchpad page and send a copy of it to the Storm mailing list to announce the release. Let Launchpad close the milestone as part of making the release. After the release is created use the 'Add file' function to upload the tarball. Be sure to also upload a valid GPG signature for it.

Prepare to develop the next version

If it hasn't already been done, create a milestone for the next version and target bugs that needs to be delivered with it. Bump the version value in the storm/__init__.py.

ReleaseProcedure (last edited 2011-10-05 16:02:48 by barry)