Make a post in Announcements channel announcing the dot release to the rest of the team with links to approved tickets and include a link to the ticket to submit the GitLab MR
2.
Dev:
PRs for hotfixes are made to release branch
Review PRs made from release branch and merge changes into the release branch as required and merge the release branch back into master once per day
B. (T-minus 3 working days) Release Candidate Cut
1.
Release Manager:
Post in the Release: Self-Managed channel the rough timing when the release candidate will be cut
Cut a Release Candidate and check CI servers running on release branch
C. (T-minus 2 working days) Release Candidate Testing
1.
QA:
If the dot release takes place during a regular release, update prev.test.mattermost.com to dot-release RCs for the previous release and keep rc.test.mattermost.com on the latest regular release version
Test the new RC to verify fixes merged to the release branch work
Post in Release: Self-Managed channel after testing
D. (T-minus 0 working days) Release Build Cut
Once bug fix release is ready to cut:
1.
Dev:
Tag a new release (e.g. 1.1.1) and run an official build
Verify hashes and GPG signatures are correct, once build is cut
Delete RCs after final version is shipped
2.
Release Manager:
Merge the Changelog PR with notes on patch releases (see example entry)
If there are any breaking compatibility changes in a supported GitLab Omnibus release (current + two previous versions) open an issue in the GitLab Omnibus repo to make sure GitLab is aware