Information for official Apache Aurora committers.
Once your Apache ID has been set up you can configure your account and add ssh keys and setup an email forwarding address at
Additional instructions for setting up your new committer email can be found at
The recommended setup is to configure all services (mailing lists, JIRA, ReviewBoard) to send emails to your @apache.org email address.
In order to create a release candidate you will need a gpg key published to an external key server and that key will need to be added to our KEYS file as well.
Create a key:
Add your gpg key to the Apache Aurora KEYS file:
git clone https://git-wip-us.apache.org/repos/asf/aurora.git (gpg --list-sigs <KEY ID> && gpg --armor --export <KEY ID>) >> KEYS git add KEYS && git commit -m "Adding gpg key for <APACHE ID>" ./rbt post -o -g
Publish the key to an external key server:
gpg --keyserver pgp.mit.edu --send-keys <KEY ID>
Update the changes to the KEYS file to the Apache Aurora svn dist locations listed below:
Add your key to git config for use with the release scripts:
git config --global user.signingkey <KEY ID>
The following will guide you through the steps to create a release candidate, vote, and finally an official Apache Aurora release. Before starting your gpg key should be in the KEYS file and you must have access to commit to the dist.a.o repositories.
* Look up the [previous release date](https://issues.apache.org/jira/browse/aurora/?selectedTab=com.atlassian.jira.jira-projects-plugin:versions-panel). * Query all issues resolved after that release date: `project = AURORA AND status in (resolved, Closed) and fixVersion is empty and resolutiondate >= "YYYY/MM/DD"` * In the upper right corner of the query result, select Tools > Bulk Edit. * Select all issues > edit issue > set 'Change Fix Version/s' to the release version. * Make sure to uncheck 'Send mail for this update' at the bottom.
Prepare RELEASE-NOTES.md for the release. This just boils down to removing the “(Not yet released)” suffix from the impending release.
Create a release candidate. This will automatically update the CHANGELOG and commit it, create a branch and update the current version within the trunk. To create a minor version update and publish it run
./build-support/release/release-candidate -l m -p
Update, if necessary, the draft email created from the
release-candidate script in step #2 and
send the [VOTE] email to the dev@ mailing list. You can verify the release signature and checksums
Wait for the vote to complete. If the vote fails close the vote by replying to the initial [VOTE] email sent in step #3 by editing the subject to [RESULT][VOTE] … and noting the failure reason (example here). You’ll also need to manually revert the commits generated by the release candidate script that incremented the snapshot version and updated the changelog. Once that is done, now address any issues and go back to step #1 and run again, this time you will use the -r flag to increment the release candidate version. This will automatically clean up the release candidate rc0 branch and source distribution.
./build-support/release/release-candidate -l m -r 1 -p
Once the vote has successfully passed create the release
IMPORTANT: make sure to use the correct release at this final step (e.g.:
-r 1 if rc1 candidate
has been voted for). Once the release tag is pushed it will be very hard to undo due to remote
git pre-receive hook explicitly forbidding release tag manipulations.
Update the draft email created fom the
release script in step #5 to include the Apache ID’s for
all binding votes and send the [RESULT][VOTE] email to the dev@ mailing list.