Differences between revisions 8 and 11 (spanning 3 versions)
Revision 8 as of 2009-08-08 05:54:08
Size: 3970
Editor: jkakar
Comment:
Revision 11 as of 2010-08-05 22:52:58
Size: 4297
Editor: jkakar
Comment:
Deletions are marked like this. Additions are marked like this.
Line 9: Line 9:
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.
AutoPPA eases the process of building packages for all supported
releases of Ubuntu.
You need to create a `~/.autoppa.conf` file
with contents similar to:
Line 16: Line 18:
branch = /home/username/src/projects/storm/trunk branch = /home/username/src/projects/storm/packaging
Line 18: Line 20:
releases = dapper hardy intrepid jaunty karmic releases = dapper hardy karmic lucid maverick
Line 21: Line 23:
You'll also need something similar to this in your `~/.dput.cf`: The branch above should be a branch of `lp:~storm/storm/packaging`.
It's best to `bzr checkout` the branch, to ensure that changes are
uploaded back to the master copy. You'll also need something
similar to this in your `~/.dput.cf`:
Line 32: Line 37:
[[https://launchpad.net/autoppa|AutoPPA]] is available on Launchpad. [[https://launchpad.net/autoppa|AutoPPA]] is available from
Launchpad.
Line 37: Line 43:
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 r
eview 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
 1. Make sure all bugs in the current active milestone on Launchpad
are in the `Fix Committed` state.

 1. R
eview the Bazaar log and make sure the NEWS file contains
 information about all the changes made since the last release.

When all the bug fixes and new features are ready in
Line 45: Line 53:
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.
 1. Edit `storm/__init__.py` and set `version` to the new version.

 1. Merge the changes from `trunk` into the `packaging` branch.
Line 53: Line 60:
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
}}}
 1. 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 build --no-merge storm 0.18-1~rc1`
Line 66: Line 69:
issues: issues (run in the `packaging` branch): ` fakeroot debian/rules binary`
Line 68: Line 71:
{{{
$
fakeroot debian/rules binary
}}}

Commit any changes needed to make the package work to the
`version-0.16` branch.
 1. Commit any changes needed to make the package work to the
 `packaging` branch.
Line 78: Line 77:
The `release` make target creates a tarball in the `dist`
directory.
 1. Run `make release` to prepare a tarball (created in the `dist`
 directory).
Line 81: Line 80:
{{{
$ 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.
 1. 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 94: Line 89:
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:
If the tarball and package are in order you can prepare the final
build.
Line 98: Line 92:
{{{
$ autoppa storm-0.16-1~storm1
}}}
 1. Use your PPA to rebuild the package, using trunk as the source
 branch, with the new release version: `autoppa build storm 0.16-1~storm1`
Line 103: Line 96:
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.
branch with a revision storing the changes made for the release
being built. This changes will be merged to the `packaging` branch
and a tag based on the new version will be added to the new revision
to track the release.
Line 107: Line 101:
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.
 1. When the new packages have finished building find them in your
PPA and copy them to the Storm Team PPA to publish them.

 1.
Upload the tarball to Launchpad using the 'Create a release'
 function from the milestone page.
Let Launchpad close the
 milestone as part of creating the release.

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

 1. Write a nice release announcement for the Launchpad page and
 send a copy of it to the Storm mailing list to announce the
 release. See the Storm mailing list archive for examples of the
 announcement.
Line 120: Line 120:
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`.
 1. If it hasn't already been done, create a milestone for the next
 version and target bugs that needs to be delivered with it.

1. 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. AutoPPA eases the process of building packages for all supported releases of Ubuntu. 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/packaging
repository = /home/username/src/autoppa-builds
releases = dapper hardy karmic lucid maverick

The branch above should be a branch of lp:~storm/storm/packaging. It's best to bzr checkout the branch, to ensure that changes are uploaded back to the master copy. 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?

  1. Make sure all bugs in the current active milestone on Launchpad

    are in the Fix Committed state.

  2. Review the Bazaar log and make sure the NEWS file contains information about all the changes made since the last release.

When all the bug fixes and new features are ready in trunk it's time to create the release.

  1. Edit storm/__init__.py and set version to the new version.

  2. Merge the changes from trunk into the packaging branch.

Preparing release-candidate packages

  1. 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 build --no-merge storm 0.18-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 (run in the packaging branch):  fakeroot debian/rules binary

  1. Commit any changes needed to make the package work to the

    packaging branch.

Preparing a release-candidate tarball

  1. Run make release to prepare a tarball (created in the dist directory).

  2. 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 you can prepare the final build.

  1. Use your PPA to rebuild the package, using trunk as the source

    branch, with the new release version: autoppa build 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 the release being built. This changes will be merged to the packaging branch and a tag based on the new version will be added to the new revision to track the release.

  1. When the new packages have finished building find them in your PPA and copy them to the Storm Team PPA to publish them.
  2. Upload the tarball to Launchpad using the 'Create a release' function from the milestone page. Let Launchpad close the milestone as part of creating the release.
  3. 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.
  4. Write a nice release announcement for the Launchpad page and send a copy of it to the Storm mailing list to announce the release. See the Storm mailing list archive for examples of the announcement.

Prepare to develop the next version

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

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