community.aegirproject.org

Release process

Tagged:
Updated by mig5 on 04/06/2011 - 02:22
AddedChangedDeleted

This page aims to document our release process.

The It's a multi-step process:

Table of Contents 
  1. 1. Running the release.sh script
  2. 2. Generating the release notes, we bump that to a beta. We push out beta releases until no more critical issues show up. Example:
  3. 3. Creating release nodes on Drupal.org
  4. 4. Publish the release notes widely

For the specifics of release naming conventions and the cycle, see the branch naming convention.

1. Running the release.sh script

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.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.sh.txt version
3. change the upgrade.sh.txt version
4. display the resulting diff
5. commit those changes to git
6. lay down the tag (prompting you for a changelog)
7. revert the commit
8. (optionally) push those changes

The operation can be aborted before step 4 and 7. 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) ).

So in short, this sums up as:

cd provision
sh release.sh 6.x-1.0-rc4 6.x-1.0-rc3
cd ../hostmaster
git tag -a 6.x-1.0-rc4
git push --tags

Back to top

2. Generating the release notes

We build complete release notes for every release. Those are made up of a summary of the release, an outline of key changes, of known issues, install and upgrade instructions and a full list of bugfixes and new features.

We have a handy bookmarklet that takes the list of issues and build a release-notes-ready list:

javascript:(function(){x%20=%20open().document;$(".views-field-title a").each(%20function()%20{%20x.write('* [' + $(this).attr('href').replace(/\/node\//, '#') + ': ' + $(this).text()+'](http://drupal.org'+$(this).attr('href')+ ')<br%20/>')%20})})()

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.

Back to top

3. Creating release nodes on Drupal.org

Once the tags are pushed and release notes published, we create a release node with an excerpt of (and a link to) the release notes so that tarballs are created and issue queue versions updated.

This needs to be done in the hostmaster and provision projects on Drupal.org.

Back to top

4. Publish the release notes widely

Once all this is done and the tarballs are generated, the release notes are published in:

Optionally, blog posts on developmentseed.org and elsewhere may go into further detail about significant changes, screencasts etc.

Back to top