Committer's Guide
Information for Aurora Scheduler committers.
Creating a gpg key for releases
Releases are signed with keys that can be found in the KEYS file. If a developer already has a GPG key, they may manually add it to the KEYS file and submit a pull request.
Developers who do not yet have a GPG key or wish to create a new one can :
-
Fork project on Github.
-
Create a key:
gpg --gen-key
-
Add your gpg key to the Aurora KEYS file:
git checkout -b addGPGKey (gpg --list-sigs <KEY ID> && gpg --armor --export <KEY ID>) >> KEYS git add KEYS && git commit -m "Adding gpg key for <GITHUB ID>"
-
Send a Pull Request adding your new key.
-
Publish the key to an external key server:
gpg --keyserver pgp.mit.edu --send-keys <KEY ID>
-
Add your key to git config for use with the release scripts:
git config --global user.signingkey <KEY ID>
Creating a release
The following will guide you through the steps to create a release candidate and an official Aurora Scheduler release. Before starting your gpg key should be in the KEYS file.
-
Ensure that all merged pull requests for this release candidate are tagged with the correct version, the changelog script will use this to generate the CHANGELOG in step #2. Merged pull requests can be found here.
-
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 release draft message created from the
release-candidate
script in step #2 and draft a new release on Github. Make sure the checkbox next toThis is a pre-release
is checked.
You can verify the release signature and checksums by running
./build-support/release/verify-release-candidate
-
Test the release for a few days and wait for community feedback. If bugs crop up, 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 you feel comfortable releasing the final version run:
./build-support/release/release
-
Update the draft message created fom the
release
script in step #5 and tag all the contributors for this release where possible.