Dot release process
Dot releases are done for high priority and high severity security issues and customer bugs. The general steps are:
- 1.The issue is escalated by the customer / customer support team and an incident channel is opened.
- 2.Our developer team investigates the issue as soon as possible.
- 3.A pull request for the issue is submitted and dev/QA reviewed, and then merged.
- 4.The bug fix is cherry-picked to the relevant release branch.
- 5.A release candidate (e.g. 7.2.1-RC1) is cut for quick final smoke tests.
- 6.After QA approval, a final release build is cut (e.g. 7.2.1) which is ready to be shared with the customer.
The time-to-fix varies, but urgent dot releases are always prioritized.
Notes:
- T-minus counts are measured in "working days" (weekdays other than major holidays concurrent in US and Canada) prior to release day.
- 1.Release Manager:
- Notify community about upcoming dot release through a Twitter announcement and in changelog with links to approved fixes and a date tagged as "TBD"
- Work with a developer to submit GitLab MR following this process and test the upgrade once the GitLab MR is merged and included in their RC
- 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
- 1.Release Manager:
- Cut a Release Candidate and check CI servers running on release branch
- 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 keeprc.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
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:
- 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
- Test the download links before and after updating the page
- Confirm that mattermost-docker has been updated to the latest version (contact the maintainer via direct message on community server if necessary)
- 3.Marketing:
- Prepare blog post for mattermost.com and Twitter announcement, and send for product marketing leads to review
Last modified 4mo ago