Creating a Release

Release Candidate (#.#.0-rc.#)

The steps for the Release Candidates are the same as for the Standard Releases, up to and including the tagging of the release. Do not update the public links, and only announce informally.

Note that Config/VERSION should not include the rc label, as this will break upgradeVersionShell.

Standard Release (#.#.0)

1. Check for latest version of dependent libraries and update if needed.
2. Review open issues in JIRA for the release. All issues should be resolved (with code committed) or moved to a future release.
3. Check for unreleased commits to hotfix. If appropriate merge into develop.
4. Update Config/VERSION, if not already updated, and make sure the version is defined in UpgradeVersionShell::$versions.

5. Merge develop into master (assuming you're already following both)

   $ git checkout develop
   $ git pull origin
   $ git checkout master
   $ git pull origin
   $ git merge develop
   (Make sure everything looks OK)
   $ git push origin master
   

6. Tag the release:

   $ git tag -a 0.8.5 -m 'COmanage Registry v0.8.5'
   $ git push origin 0.8.5
   

7. Notify the lead of the packaging/container team of the new tag.
8. Wait for notification from the packaging/container team that packages/images are ready.
9. Test the release, including upgrading QA servers and installing/deploying from scratch.
10. Update download link at Directory Installation or Registry Installation - Source.
11. Update TAP release page.
12. Review Registry Data Model and update the status of tables as appropriate.
13. In JIRA, flag the release as "Released" with today's date.
14. Update Release History.
15. Update Home, including the Download link and About This Release.
16. Update the COmanage Product Roadmap.
17. If there are any unrelated bug fixes in the prior hotfix series (#.#-1.#), simultaneously release that as the "last maintenance release" of the previous series.
18. Announce (to comanage-users, comanage-announce, and comanage-community). If appropriate and approved, credit additional funding sources.

Bug Fix Release (#.#.#)

A bug release is intended to quickly fix bugs discovered with a standard release. These releases are indicated using a revision number after the related standard release number. There is not necessarily a corresponding JIRA release.

1. Review open issues in JIRA for the release. All issues should be resolved (with code committed) or moved to a future release.
2. Update Config/VERSION, if not already updated, and make sure the version is defined in UpgradeVersionShell::$versions.
3. Merge changes from the hotfix release branch into master and develop.
   1.  If master has moved on to a new minor release, do not merge into either branch. You may wish to cherry pick commits if appropriate.

4. Tag the release from the hotfix branch (though you can also use master if you merged the hotfix branch into master):

   git tag -a 0.8.5 -m 'COmanage Registry v0.8.5'
   $ git push origin 0.8.5
   

5. Notify the lead of the packaging/container team of the new tag.
6. Wait for notification from the packaging/container team that packages/images are ready.
7. Test the release, including upgrading QA servers and installing/deploying from scratch.
8. Update download link at Directory Installation or Registry Installation - Source.
9. Update TAP release page.
10. If appropriate, flag the release in JIRA as "Released" with today's date.
11. Create the next bug fix release in JIRA (#.#.#+1, unless there's a simultaneous feature release, in which case #.#+1.1).
12. Update Release History.
13. Update Home, including the Download link and About This Release.
14. Update the COmanage Product Roadmap (if appropriate).
    
15. Announce (to comanage-users, comanage-announce, and comanage-community). If appropriate and approved, credit additional funding sources.