Release Process

ARIA follows the ASF's release process.
The complete information may be found over at the following links:1.

1. https://www.apache.org/dev/#releases

...

1. https://www.apache.org/legal/release-policy.html

...

1. https://www.apache.org/dev/release-distribution.html

...

1. https://www.apache.org/dev/release-publishing.html

...

1. https://www.apache.org/dev/release-signing.html

...

1. http://incubator.apache.org/incubation/Incubation_Policy.html#Releases

...

1. http://incubator.apache.org/guides/releasemanagement.html

A simplified summary of specific steps one should take when attempting to release ARIA follows below.

Standard release process:

...

1. build and put on dev

...

1. Start a voting thread on the ARIA dev mailing list (link example).
   The vote must:

   ...

   1. 1. Last for at least 72 hours

   ...

   1. 1. Receive at least three +1 votes from PPMC (ARIA's PMC) members

   ...

   1. 1. Have more +1 votes than -1 votes in total

   ...

   1. Start a voting thread on the Incubator's general mailing list (link example)
      The 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).

   ...

   1. finalize release (tag, mv to /dist/release, pypi)

   ...

   1. Wait 24 hours (For the mirrors to catch up)

   ...

   1. Make an announcement about the release on the ARIA dev and Incubator's general mailing lists (link example)

   ...

   1. 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

   ...

   1. set JIRA version to released

    

   
   Process for releasing a backport patch version (e.g. 0.1.1):

   ...

   1. Add a new version on JIRA

   ...

   1. git checkout the 0.1.0 tag as a "0.1.1-rc" branch

   ...

   1. Create a JIRA ticket for updating the VERSION file to 0.1.1 (e.g. ticket no. ARIA-1234)

   ...

   1. Update the VERSION file to 0.1.1 and commit under ARIA-1234

   ...

   1. git cherry-pick commits for bug fixes (and possibly tasks, but not features)

   ...

   1. Create a JIRA ticket for updating the CHANGELOG (e.g. ticket no. ARIA-2345)

   ...

   1. Update the CHANGELOG (according to backported commits) and commit under ARIA-2345

   ...

   1. Update backported JIRA issues' "fixVersion" field to also include 0.1.1

   ...

   1. git push and wait for CI tests to complete successfully

   ...

   1. Create release candidate packages using the release/asf-release.sh script

   ...

   1. Follow up on the remaining steps in the stanard release process

   ...

   1. git cherry-pick the changes to CHANGELOG (ARIA-2345 commit) into master (possibly re-sorting the CHANGELOG file's order of releases)