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


A. (T-minus 4 working days) Code Complete

  1. 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.
    • 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. 2.
    • 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. 1.
    • 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. 1.
    • If the dot release takes place during a regular release, update to dot-release RCs for the previous release and keep 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. 2.
    • 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. 1.
    • 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. 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. 3.
    • Prepare blog post for, 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