Links

Dot release process

Dot releases are done for high priority and high severity security issues and customer bugs. The general steps are:
  1. 1.
    The issue is escalated by the customer / customer support team and an incident channel is opened.
  2. 2.
    Our developer team investigates the issue as soon as possible.
  3. 3.
    A pull request for the issue is submitted and dev/QA reviewed, and then merged.
  4. 4.
    The bug fix is cherry-picked to the relevant release branch.
  5. 5.
    A release candidate (e.g. 7.2.1-RC1) is cut for quick final smoke tests.
  6. 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.
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 other than major holidays concurrent in US and Canada) prior to release day.

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

  1. 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"
    • Open an issue in the GitLab Omnibus mentioning a dot release is coming. See example
    • 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. 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. 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. 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. 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. 2.
    Release Manager:
    • Merge the Changelog PR with notes on patch releases (see example entry)
    • Update the version archive
    • 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
    • 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 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.
  3. 3.
    Marketing: