1. Make sure everything is committed to version control.
2. Branch trunk to a release-X.Y branch.
3. Run automatic tests.
   • typically: make clean all check
4. Update version number, NEWS, debian/changelog, setup.py.
5. Test-build upstream tarball, Debian packages, other release files using unperish.
   • # unperish clean deb --basetgz=/home/pbuilder-tgz/sid-amd64-debian.tgz lintian
   • # unperish --verbose dch --upload-target=squeeze deb --basetgz=/home/pbuilder-tgz/squeeze-amd64-custom.tgz
6. Merge release branch to trunk.
   • # cd ../trunk && bzr merge ../release-X.Y
7. Build again, from trunk, see commands above.
8. # debsign ../build-area/*.changes
9. # dput ftp-master ../build-area/something.changes
10. # dput code ../build-area/something-else.changes
11. Build and upload for other architectures too, if relevant.
12. Tag the revision in version control.
    • # bzr tag PROJECTNAME-X.Y (previously version_X_Y, but not anymore)
13. Push version control.
    • # bzr push
14. Update bug tracker.
15. Copy NEWS, README, examples, other relevant files to the project home page.
    • # unperish publish-docs --web-directory=$HOME/liw.fi/PROJECT
    • # unperish rsync-publish --rsync-glob=doc/_build/html/. --rsync-to=pieni.net:code.liw.fi/PROJECT/docs/.
16. Upload to pypi, if relevant.
    • # python setup.py register
17. Announce on the relevant forums.
    • my blog
    • a dedicated announcement mailing list
    • identi.ca
18. Clean up build artifacts, mainly from ...

On version numbers

By default, my projects use X.Y as version numbers, where X changes whenever there is a really good reason to do so, and Y increments for each new release.

If there is a bug-fix-only release, then X.Y.Z can be used as the version number.