Security release process

If a security fix release is required, run through the below steps.
Please refer to the Dot Release Playbook for a most up-to-date checklist.
Release Timeline
Notes:
All cut-off dates are based on 10am (San Francisco Time) on the day stated.
T-minus counts are measured in "working days" (weekdays, Monday through Friday, excluding the listed statutory holidays) prior to release day.
A. (T-minus 4 working days) Code Complete
1.Release Manager:
Once the list of security issues to be fixed is finalized, post this checklist in Release Checklist channel
Notify community about upcoming security release through a Twitter announcement and in changelog with links to approved fixes and a date tagged as "TBD"
Notify GitLab release team about upcoming security release in their Slack channel
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.
Open a ticket to submit GitLab Omnibus RC install of Mattermost​
Make a post in Announcements channel announcing the security 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.Build:
Verify with Release Manager before cutting any new dot release RCs (approved fixes should be merged)
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 Discussion channel after testing
2.Logistics:
If the security researcher has not previously received a security researcher mug, order one for them
D. (T-minus 0 working days) Release Build Cut
Once security 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:
Update the Changelog
Update the version archive​
Update the ESR documentation​
Update Mattermost server download page with the links to the EE and TE bits
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)
Contact owners of community installers or submit PRs to update install version number
For Puppet, Heroku and Ansible Playbook, post to Installers and Images channel announcing the new release. See example.
For Chef Cookbook, open a new issue to announce the new release. See example.
For Yunohost, open a new pull request to update the version. See example.
For OpenShift, open a new pull request to update the version. See example.
Update Security Research Hall of Fame on the Responsible Disclosure Policy page
Post Mattermost Security Updates 30 days after the dot release has shipped
Update Security Issues spreadsheet with issue number from posted update (e.g. v3.2.0.1)
3.Marketing:
Prepare blog post for mattermost.com, MailChimp email blast, and Twitter announcement, and send to security team and product marketing leads for review. Once reviewed, schedule for 08:00 PST on the day after dot release

Boards release process

Mobile app release process

Last modified 4mo ago