THIS IS A TEST INSTANCE. ALL YOUR CHANGES WILL BE LOST!!!!
ARIA follows the ASF's release process.
The complete information may be found over at the following links:
- https://www.apache.org/dev/#releases
- https://www.apache.org/legal/release-policy.html
- https://www.apache.org/dev/release-distribution.html
- https://www.apache.org/dev/release-publishing.html
- https://www.apache.org/dev/release-signing.html
- http://incubator.apache.org/incubation/Incubation_Policy.html#Releases
- http://incubator.apache.org/guides/releasemanagement.html
A simplified summary of specific steps one should take when attempting to create a release for ARIA follows below.
Standard release process:
- Ensure the state of the relevant branch is release-ready (tests are passing; CHANGELOG is up to date; RAT check is valid)
- Create the release-candidate packages by running the "asf-release.sh" script like so:
asf-release.sh candidate <git-branch>
Where <git-branch> is the branch for the release (e.g. "master"). - Verify the packages are on Apache's dist/dev, and that the sdist and bdist packages are on test PyPI
- If this is your first time creating a release for ARIA, make sure to update the KEYS file with your key
- Start a voting thread on the ARIA dev mailing list (example).
To pass, the vote must:- Last for at least 72 hours
- Receive at least three +1 votes from PPMC (ARIA's PMC) members
- Have more +1 votes than -1 votes in total
- After the vote has passed, send a vote result announcement (example)
- After the vote has passed, start a new voting thread on the Incubator's general mailing list (example)
This vote has similar rules to the previous one, only this time only IPMC (Incubator's PMC) member's votes are binding.
Note that everyone else is still welcome to share their vote (or copy their +1 vote from the dev mailing list's vote). - After the second vote has passed, send a vote result announcement (example)
- Finalize the release:
- Copy the new packages created on dist/dev to dist/release
(Don't forget to also copy the KEYS file if you've updated it on dist/dev) - Tag the branch used to create the release candidate on Github with the release's version
- Upload the sdist and bdist packages onto PyPI
asf-release.sh package <git-branch>
However, these actions being somewhat delicate, it might be better to run them manually, using the "asf-release.sh" script as a reference. - Copy the new packages created on dist/dev to dist/release
- Wait 24 hours (For the mirrors to catch up)
- Make an announcement about the release on the ARIA dev and Incubator's general mailing lists (example)
- Add download links to the website's download page
Note: Download links should point to ASF mirrors like so:
https://www.apache.org/dyn/closer.cgi/incubator/ariatosca/0.1.0-incubating
Links for signatures and hash checksums should still point to the ASFs main website, e.g.:
http://www.apache.org/dist/incubator/ariatosca/0.1.0-incubating/source/apache-ariatosca-0.1.0-incubating.tar.gz.asc
See more information here: http://www.apache.org/dev/release-download-pages.html#links - Set the version to "released" status on JIRA
Process for releasing a backport patch version (e.g. 0.1.1):
- Add a new version on JIRA
- git checkout the 0.1.0 tag as a "0.1.1-rc" branch
- Create a JIRA ticket for updating the VERSION file to 0.1.1 (e.g. ticket no. ARIA-1234)
- Update the VERSION file to 0.1.1 and commit under ARIA-1234
- git cherry-pick commits for bug fixes (and possibly tasks, but not features)
- Create a JIRA ticket for updating the CHANGELOG (e.g. ticket no. ARIA-2345)
- Update the CHANGELOG (according to backported commits) and commit under ARIA-2345
- Update backported JIRA issues' "fixVersion" field to also include 0.1.1
- git push and wait for CI tests to complete successfully
- Create release candidate packages using the release/asf-release.sh script
- Follow up on the remaining steps in the standard release process
- git cherry-pick the changes to CHANGELOG (ARIA-2345 commit) into master (possibly re-sorting the CHANGELOG file's order of releases)