This page describes the steps that a release manager needs to take to perform a release of Apache CloudStack.
(Thanks to the couchdb project for a great template to use for this procedural document!)
Prior to an official vote, start a thread on the cloudstack-dev mailing list, specifically asking for comments on the project's readiness to cut a release.
Once it appears that any outstanding blockers have been addressed, you can proceed to the next step.
Update your local git repo from the ASF repository:
git fetch origin
Check out the release branch:
git checkout X.Y
( or if you haven't already checked it out locally with remote tracking enabled: git checkout -b X.Y origin/X.Y )
Make sure your local copy exactly matches the remote repo:
git reset --hard HEAD git clean -qfxd git rebase origin/X.Y
Then run the source build script (Replacing the parameters: X.Y.Z.0=your official version number for the release; X.Y=the branch (can be master) that the release is coming from; CCCC=the GPG Key to sign both the artifacts and the git tag with):
tools/build/build_asf.sh -v X.Y.Z.0 -b X.Y -t -u CCCC -s /path/to/the/source/dir -c
( optionally specifying your local directory layout - see build_asf.sh -h for details )
This will automatically commit (the -c) to the cloudstack dist dev folder (on SVN). This is the staging area for Apache CloudStack distributions.
Get the commit-sh to vote against for your VOTE email. This comes from the output of the command above. Example:
completed. use commit-sh of b25d27d80b62de3408041821aa99e68712ae2728 when starting the VOTE thread
A RC branch will have been created. When a vote is done you can either delete it or merge it back depending on the outcome.
Test the Build
Follow the instructions documented in your release branch's test procedures wiki page.
If your personal tests pass, you are ready to propose the release to the community.
Email the firstname.lastname@example.org mailing list, using the following template:
SUBJECT: [VOTE] Apache Cloudstack X.Y.Z
Hi All, I've created a X.Y.Z.0 release, with the following artifacts up for a vote: Git Branch and Commit SH: https://git-wip-us.apache.org/repos/asf?p=cloudstack.git;a=shortlog;h=refs/heads/X.Y Commit: XXXXXXXXXXXXXXXXX Source release (checksums and signatures are available at the same location): https://dist.apache.org/repos/dist/dev/cloudstack/X.Y/ PGP release keys (signed using XXXXXXXX): https://dist.apache.org/repos/dist/release/cloudstack/KEYS Vote will be open for 72 hours. For sanity in tallying the vote, can PMC members please be sure to indicate "(binding)" with their vote? [ ] +1 approve [ ] +0 no opinion [ ] -1 disapprove (and reason why)
After 72 hours, the vote can be closed.
If (after tallying the vote) the binding +1 votes are not in the majority, the issues noted need to be addressed and process starts again. You need to send out a results email (or a less formal abort email) for the VOTE thread.
If the vote passes, then send a [RESULTS] vote to the dev list. Template below:
SUBJECT: [RESULT][VOTE] Apache CloudStack X.Y.Z
Hi all, After 72 hours, the vote for CloudStack X.Y.Z.0  *passes* with Z PMC + Z non-PMC votes. +1 (PMC / binding) * person +1 (non binding) * person 0 none -1 none Thanks to everyone participating. I will now prepare the release announcement to go out after 24 hours to give the mirrors time to catch up.
merge and push the release candidate branch into the release branch. Parts of this procedure is explained further on in more generic terms.
$ git checkout X.Y-RC20141121T0341 $ git tag X.Y.Z.0 $ git push origin X.Y.Z.0 $ git checkout X.Y $ git merge X.Y-RC20141121T0341 $ git branch -m X.Y-RC20141121T0341 GA-X.Y.Z.0 # renames the old release candidate to something that makes sense $ git push origin X.Y $ git push origin :X.Y-RC20141121T0341 # deletes the old branch
Keeping the branch around as GA-X.Y.Z is not strictly necessary. Neither is tagging the release as the commit-id is really the part that is voted on.
Run the version reset script setting the latest pom version numbers to be equal to the next bug-fix release for the branch (including SNAPSHOT). Example:
$ tools/build/setnextversion.sh -b [branch] -v X.Y.A.0-SNAPSHOT -s ~/cloudstack-release $ git push origin [branch]
The release should have already been tagged in your local repo when you used the build_asf.sh script (the -t option). However, you need to push that tag once the VOTE passes:
$ git push origin X.Y.Z.0
find a JIRA administrator/PMC member to go to https://issues.apache.org/jira/plugins/servlet/project-config/CLOUDSTACK/versions and enter the release date for the version
Move the release artifacts into place (replace X.Y.Z.0 with the release number, and replace Y.Y.Y with the previous release number):
# svn mv -m "Publishing X.Y.Z.0 release" https://dist.apache.org/repos/dist/dev/cloudstack/X.Y.Z.0/ https://dist.apache.org/repos/dist/release/cloudstack/releases/
Wait 24 hours for the mirrors to catch up.
Update http://cloudstack.apache.org/downloads.html to point to the new release, and add the older release to the archive list.
Remove the prior release from the release dist area (it's still archived):
# cd /tmp/cs-release/releases # svn rm Y.Y.Y # svn commit -m "Removing Y.Y.Y release"
For some releases, the CloudStack security team may be waiting for release announcement so they can simultaneously announce any security advisories related to the release.
The release notes at Read The Docs must be updated to include the changes in the release and also the upgrade procedure to the new release. At a minimum, fixed_issues and about need updating in cloudstack-docs-rn
The current version of CloudStack is referenced in a few places in the installation documentation.
The community 'hosters' at download.cloudstack.org and packages.shapeblue.com should be notified and requested to create and upload the convenience binaries to their sites.
After waiting 24 hours for the ASF mirrors to catch up, the release is ready to be announced. Send separate announcement emails to email@example.com, firstname.lastname@example.org, email@example.com, firstname.lastname@example.org and email@example.com. This is best done using your apache.org address, so that the announcement gets moderated through to the lists.
The contents of the message should have been discussed on firstname.lastname@example.org first.
Link to boilerplate maintenance release announcement
The downloads page at http://cloudstack.apache.org/downloads.html must be updated - this involves updating the /data/cloudstack.yaml in http://github.com/apache/cloudstack-www and then building the website (build.sh).
Add a post at https://blogs.apache.org/
You need author permissions on Apache Roller, which need to be given by an Admin of the Apache CloudStack project blog.
Install subversion on your release environment (preferably Linux or OSX based).
cd /tmp svn co https://dist.apache.org/repos/dist/release/cloudstack/ --depth empty cd cloudstack svn up KEYS # this will get the latest KEYS file # append your GPG key to the KEYS file, see the KEYS file for instructions as well. # gpg --list-sigs <key ID> >> KEYS # gpg --armor --export <key ID> >> KEYS svn diff svn add KEYS svn commit KEYS -m "KEYS: add key of apache_id FirstName LastName to CloudStack KEYS"