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

1. https://www.apache.org/dev/#releases
2. https://www.apache.org/legal/release-policy.html
3. https://www.apache.org/dev/release-distribution.html
4. https://www.apache.org/dev/release-publishing.html
5. https://www.apache.org/dev/release-signing.html
6. http://incubator.apache.org/incubation/Incubation_Policy.html#Releases
7. 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
2. Start a voting thread on the ARIA dev mailing list (link example).
   The vote must:
   1. Last for at least 72 hours
   2. Receive at least three +1 votes from PPMC (ARIA's PMC) members
   3. Have more +1 votes than -1 votes in total
3. 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).
4. finalize release (tag, mv to /dist/release, pypi)
5. Wait 24 hours (For the mirrors to catch up)
6. Make an announcement about the release on the ARIA dev and Incubator's general mailing lists (link example)
7. 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
8. set JIRA version to released

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

1. Add a new version on JIRA
2. git checkout the 0.1.0 tag as a "0.1.1-rc" branch
3. Create a JIRA ticket for updating the VERSION file to 0.1.1 (e.g. ticket no. ARIA-1234)
4. Update the VERSION file to 0.1.1 and commit under ARIA-1234
5. git cherry-pick commits for bug fixes (and possibly tasks, but not features)
6. Create a JIRA ticket for updating the CHANGELOG (e.g. ticket no. ARIA-2345)
7. Update the CHANGELOG (according to backported commits) and commit under ARIA-2345
8. Update backported JIRA issues' "fixVersion" field to also include 0.1.1
9. git push and wait for CI tests to complete successfully
10. Create release candidate packages using the release/asf-release.sh script
11. Follow up on the remaining steps in the stanard release process
12. git cherry-pick the changes to CHANGELOG (ARIA-2345 commit) into master (possibly re-sorting the CHANGELOG file's order of releases)