Release overview
Mattermost ships with a new version once a month for both cloud and self-hosted customers.
Release numbering
Mattermost numbers stable releases in the following format: [Major Build Number].[Minor Build Number].[Patch Build Number]
Major build number:
Purpose: Major system releases introduce significantly new functionality or change existing product behavior
Release frequency: Once a year. Major system releases are infrequent
Example: v1.x.x, v2.x.x
Minor build number:
Purpose: Introduce new features, bug fixes and performance improvements
Release frequency: Monthly cadence
Example: v1.2.x, v1.4.x
Patch build number:
Purpose: Patch existing releases when severe bug fixes or security patches are required
Release frequency: As required
Example: v1.2.5, v1.2.6
Objectives
The goal is to deliver value to users quickly by a) shipping fast to get features to customers quickly for experimentation/feedback, and b) iteratively behind feature flags as a protection if any issues arise. This document outlines the principles and guidelines for how we release a new update of each product line on a monthly basis.
Release Principles
Focus on High Impact by shipping every new feature and any riskier code changes behind a feature flag
Each development team is individually responsible for quality and deciding if a feature should be included in a release or not (with the release team giving guidelines). This may mean shipping more patch releases, but we can manage some of this by using feature flags. This also requires good test automation coverage.
Automate
Automate release processes and tasks.
Automate release tests and have E2E tests for features.
Earn Trust by communicating to external and internal stakeholders clearly
Enables us to make expectations for releases clear for all stakeholders.
Make expectations for each release clear (release dates, etc.). Communicate. Ensure that everyone on the team is familiar with the release processes.
Release notes, minimum version requirements, and any important upgrade notes need to be available for customers and communicated via docs, blog, emails, and channels.
Earn Trust by including all stakeholders (Tech Writers, Marketing, QA, etc.) early in the release process
Enables us to avoid missing key tasks and to avoid last minute work.
E.g. When opening a PR, add a “Docs/Needed” label for any PRs that need docs and communicate to Tech Writers. This ensures that we have time to complete docs on time.
Make tracking bugs and testing requirements easy. E.g:
Resolve Jira tickets for QA when PRs are merged (and cherry-picked).
Add QA test steps to Jira tickets and/or PRs.
Add Fix Versions and Milestones in Jira/PRs for bugs/tickets for easy tracking.
Add clear Release Notes on PRs.
Achieve Customer Obsession by doing retrospectives on release issues and monitoring customer/community release bug reports after releases
This allows us to learn from issues so that they don’t happen again and to fix critical bugs asap.
Retrospectives for issues and dot releases are important.
Monitor community and customer reports in GitHub, Forum, and channels like Ask R&D, in partnership with the Support team.
Release Cycles
Release dates communication
Release dates are currently communicated in the following ways.
Channels
Mattermost Release Dates Calendar
Lists key release dates and deadlines.
PM and R&D meetings
Updates are provided on upcoming key dates and/or features as needed.
Productboard
Spreadsheet
Plugin Release Processes
Tracking feature flags
Adding milestones on PRs and Jira tickets
If the PR is scheduled for a specific Mattermost release, please add the
Cherry-pick Approved
label and self-managed milestone on the PR. The Release Manager keeps track of PRs with theCherry-pick Approved
label and self-managed milestone on a daily basis.The Release Manager also tracks regression bugs and aims to ensure that they get fixed for the next release.
A fix version is added in Jira to track regression bug fixes for Mattermost releases.
Triaging Mattermost customer issues
When triaging a bug report, consider the following:
Impact of the bug on customers.
Severity of the issue.
Risk and effort of reverting to the last version or fixing a bug.
Criteria
"We need to revert to the last version" process:
Crash or all services are down due to a bug; affects some to all Mattermost Cloud customers.
"We need to release this ASAP" process:
A severe regression or loss of functionality; affects some to all Cloud customers.
"It's OK to wait until next release" process:
Loss of function, but little impact on Cloud customers.
Responders
Who is making the decision on which process above we need to follow?
In some cases it's the customer support teams or Cloud teams, and in some cases it's other people such as the Release Manager or developers who notice or get notified about the report.
Bugs will be fixed by either the CRE team or by respective development teams, depending on availability and expertise.
Frequently Asked Questions
Q: What is the release cycle for the React Native mobile apps?
A: The mobile apps follow the same monthly release cycle as Mattermost Server/Webapp, releasing on the 16th of each month.
Q: What is the release cycle for the Mattermost Desktop app?
A: Desktop releases are shipped every 3 months starting in March, 2023. For more details, see https://handbook.mattermost.com/operations/research-and-development/product/release-process/desktop-release.
Q: When do I need to have a feature PR to be included into the next release?
A: Aim to have the PR merged before the Feature Complete deadline. The earlier in the monthly cycle the PR is merged, the higher the chances are for it to be included in that month's release. The quality of our releases is important and feature PRs are not normally cherry-picked to a release branch.
Q: How can I determine if my merge request will make it into the next release?
A: The Release Manager adds PR milestones and Jira fix versions for tracking. You can also check the release branches (e.g. in the mattermost repo) to see what's included.
Q: Do we use Playbooks for releases?
A: Yes, playbooks are used for cloud & self-hosted, mobile and desktop releases, and for dot releases and plugin releases.
Q: How are PRs merged for release?
A: PRs are first merged to master. As needed, the dev who submitted the fix is also responsible for cherry-picking it to the release branch after a release branch has been cut.
Q: How is cherry-picking done?
Q: What version is community.mattermost.com kept on?
A: Normally on
master
branch and it updates daily.
Q: How to remove a feature/bug from a release?
A: The feature flag is turned off. Another option is reverting the feature from the
master
andrelease
branches.
Q: How are NOTICE.txt PRs submitted?
A: PRs are first merged to
master
. The dev reviewer is responsible for helping cherry-picking it to therelease
branch as needed.
Q: Is an improvement a feature or a bug?
A: Usually features/story tickets.
Q: How does release team monitor what changes went into a release?
Q: How does translations branching work?
A: The translation PR will be submitted against the master branch.
Q: What is the process for community PRs?
A: Review, merge, and cherry-pick as needed.
Q: What information does the Customer Support team need for Cloud releases?
The Announcements channel in the Staff team is used for release updates and for posting the changelog.
Last updated