Release process
This page aims to document our release process. It's a multi-step process:
- 1. Make sure Jenkins is all green
- 2. Running the release.sh script
- 3. Test the manual install in Jenkins
- 4. Generating the release notes
- 5. Creating release nodes on Drupal.org
- 6. Build the release in Jenkins again
- 7. Build the Debian packages
- 8. (eventually) Build the release in Jenkins yet again
- 9. Publish the release notes widely
For the specifics of release naming conventions and the cycle, see the branch naming convention.
1. Make sure Jenkins is all green
Look into Jenkins to see if all tasks have been performed without errors since the last commit. If there is an error, fix it before the release.
2. 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 upgrade.sh.txt version
3. display the resulting diff
4. commit those changes to git
5. lay down the tag (prompting you for a changelog)
6. revert the commit
7. (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.2
cd ../hostmaster
git tag 6.x-1.2
git push --tags3. Test the manual install in Jenkins
Before making a full release, test the release in Jenkins. To do so, create a new build based on the 6.x-1.0 install build. ''Note'': it would be important to eventually factor out this code so that we don't have duplicates all over the place like this...
You'll need to modify the fetch_provision() function from:
def fab_fetch_provision():
print "===> Fetching Provision"
fabric.run("su - -s /bin/sh aegir -c 'php /var/aegir/drush/drush.php dl -y --destination=/var/aegir/.drush provision-6.x-1.0'", pty=True)to:
def fab_fetch_provision():
print "===> Fetching Provision"
fabric.run("su - -s /bin/sh aegir -c 'mkdir ~/.drush'", pty=True)
fabric.run("su - -s /bin/sh aegir -c 'git clone http://git.drupal.org/project/provision.git ~/.drush/provision'", pty=True)
fabric.run("su - -s /bin/sh aegir -c 'cd ~/.drush/provision && git checkout 6.x-1.1'", pty=True)... to checkout the tag. (We need to do it in two steps since it's unfortunately impossible to checkout a tag from clone directly.)
If the build fails, delete the remote tags, fix the bugs and start again.
4. 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.
5. 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.
6. Build the release in Jenkins again
At this point, it's possible that the tarballs on Drupal.org were not created properly. We want to test the real procedure, so fix the jenkins build to download provision with drush instead of git:
fabric.run("su - -s /bin/sh aegir -c 'php /var/aegir/drush/drush.php dl -y --destination=/var/aegir/.drush provision-6.x-1.0'", pty=True)7. Build the Debian packages
Follow these detailed instructions. Then upload the result to http://debian.koumbit.org (?)
8. (eventually) Build the release in Jenkins yet again
... once we have such a script (ref.: http://drupal.org/node/1128614)
9. Publish the release notes widely
Once all this is done and the tarballs are generated, the release notes are published in:
- The handbook (this is where the release notes live!)
- A link to the release notes on the frontpage block
- An event in the calendar
- A discussion post (don't forget to make it 'sticky' & remove stickiness from the previous announcement)
- Update the version in the script upgrade page
- The topic of the IRC channel
- The aegir-announce mailing list
- Twitter as @aegirproject
Optionally, blog posts on koumbit.org, greenbeedigital.com.au, and elsewhere may go into further detail about significant changes, screencasts etc.