Release process
This page aims to document our release process.
In general, each major Hostmaster release comprises of a simultaneous release of all the modules part of the project. We generally go through a few releases before doing the first release.
First an alpha is released to test new functionalities and to proceed accomplishing the goals decided in the Project Roadmap for that major version.
When we feel we're getting close to a production-ready release, we bump that to a beta.
Then we go into feature freeze and release a first release candidate (RC).
If no critical bug is found, a complete release is done, otherwise critical bugs are fixed and a new RC is done. That cycle repeats until no critical bugs are found.
Each time we make a new release, we run a script called 'release.sh' in provision
This script should only be used by the core dev team when doing an official release. If you are not one of those people, you probably shouldn't be running this.
This script does all the 'hard' work in that it doesn't forget all the very many places to edit version numbers etc of relevant documentation and other scripts. This includes INSTALL.txt, UPGRADE.txt, install.sh.txt and upgrade.sh.txt.
Paraphrasing from the script itself:
The following operations will be done:
1. change the makefile to download tarball
2. change the INSTALL.txt to point to tagged install.sh
3. change the UPGRADE.txt to point to release tags
4. change the install.sh.txt version
5. change the upgrade.sh.txt version
6. display the resulting diff
7. commit those changes to git
8. lay down the tag (prompting you for a changelog)
9. revert the commit
10. (optionally) push those changes
The operation can be aborted before step 6 and 9. Don't forget that as long as changes are not pushed upstream, this can all be reverted (see git-reset(1) and git-revert(1) ).- Tarballs are automatically created on http://files.aegirproject.org with associated md5sums once the tag is pushed. The install/upgrade documentation scripts in that release were automatically modified so that the URLs to those tarballs reflects the correct release.
The list of bugs, features and other issues resolved are collated together, usually in a shared piratepad somewhere.
The developers then proceed to format/edit the list of fixes as well as list other significant information/changes for this release. These notes end up becoming the Release Notes for the release.
The release notes are published on:
- News on community.aegirproject.org
- GDO
- The aegir-announce mailing list
- Twitter as @aegirproject
- Optionally, blog posts on developmentseed.org and elsewhere may go into further detail about significant changes, screencasts etc.