|
Size: 2520
Comment: Initial notes, still incomplete this is a work in progress
|
Size: 4062
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. 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 27: | Line 18: |
| branch = /home/username/src/projects/storm/trunk | branch = /home/username/src/projects/storm/packaging |
| Line 29: | Line 20: |
| releases = dapper hardy intrepid jaunty karmic | releases = dapper hardy karmic lucid maverick |
| Line 32: | 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 43: | Line 37: |
| 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: |
[[https://launchpad.net/autoppa|AutoPPA]] is available from Launchpad. |
| Line 47: | Line 40: |
| {{{ $ autoppa --no-merge storm-0.15-1~rc2 }}} |
|
| Line 51: | Line 41: |
| ``FIXME`` Provide instructions explaining AutoPPA installation. | == Are you ready? == 1. Make sure all bugs in the current active milestone on Launchpad are in the `Fix Committed` state. 1. 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 [[https://code.launchpad.net/~storm/storm/trunk|trunk]] it's time to create the release. 1. Edit `storm/__init__.py` and set `version` to the new version. 1. Merge the changes from `trunk` into the `packaging` branch. == Preparing a release-candidate package == 1. Build the package in your own PPA so that you can test them before publishing them in the official Storm PPA: `autoppa build storm 0.18-1~rc1` |
| Line 54: | Line 65: |
| 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 (run in the `packaging` branch): `fakeroot debian/rules binary` |
| Line 59: | Line 71: |
| {{{ $ 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. |
Any changes made for the build will have been committed to the `packaging` branch. |
| Line 70: | Line 77: |
| {{{ $ ./setup.py sdist --formats bztar }}} |
1. Run `make release` to prepare a tarball (created in the `dist` directory). 1. This will create `dist/storm-0.17.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 87: |
| == Creating the final release packages and tarball == | == Decide whether to move on == |
| Line 77: | Line 89: |
| When the package is perfect and ready for redistribution rebuild it with the release version: |
If everything looks good move onto the next step. Otherwise, fix the problems and build a new version of the package. Bump the `stormN` part of the version string to `stormN+1`. |
| Line 80: | Line 93: |
| {{{ $ autoppa storm-0.15-1~storm1 }}} |
|
| Line 84: | Line 94: |
| 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. |
== Creating and publishing the new tarball and packages == If the tarball and package are in order you can copy the package to the official Storm PPA and upload the tarball to Launchpad. 1. Find the new packages 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. == 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. 1. Bump the `version` value in the `storm/__init__.py`. |
Preparing a release is a fairly straight-forward process despite appearances to the contrary.
Contents
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?
- Make sure all bugs in the current active milestone on Launchpad
are in the Fix Committed state.
- 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.
Edit storm/__init__.py and set version to the new version.
Merge the changes from trunk into the packaging branch.
Preparing a release-candidate package
- Build the package in your own PPA so that you can test them before publishing them in the official Storm PPA:
autoppa build 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
Any changes made for the build will have been committed to the packaging branch.
Preparing a release-candidate tarball
Run make release to prepare a tarball (created in the dist directory).
This will create dist/storm-0.17.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.
Decide whether to move on
If everything looks good move onto the next step. Otherwise, fix the problems and build a new version of the package. Bump the stormN part of the version string to stormN+1.
Creating and publishing the new tarball and packages
If the tarball and package are in order you can copy the package to the official Storm PPA and upload the tarball to Launchpad.
- Find the new packages 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. Let Launchpad close the milestone as part of creating 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.
- 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
- 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.