Desktop app release process
This document outlines the release process for the Mattermost desktop app.
Desktop App releases follow a fixed schedule of 4 releases per year. Releases ship quarterly by the 16th of March, June, September, and December of each year.
A dot release will be prepared sooner if Electron releases a security update, or if other urgent bugs are found.
Notes:
- All cut-off dates are based on 15:00 GMT (UTC-00) 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.
Pre-work for the current release begins at the code complete date of the previous release. See "Code Complete and Release Candidate Cut" section below for details.
No pull requests for features should be merged to the current release after this date. In special cases, exceptions can be made by the Release Manager.
- 1.Release Manager:
- Post this checklist in Desktop App channel
- Ensure that feature PR reviews are prioritized, and post a list of outstanding feature PRs in the Desktop App channel
- After release branches are cut, ask dev to cut RC1 for QA testing
- After RC1 is cut, make an announcement for R&D to use the RC as their daily client to get more test coverage
- Submit changelog with updates for improvements, bug fixes, known issues, and contributors
- Ask PMs if there are any notable breaking changes or deprecated features in the release
- Start posting a daily Zero Bug Balance query (posted until zero bugs or day of release)
- Create meta issue for release in GitHub to let contributors and users know about the upcoming release. See example issue
- Confirm date of marketing announcement for the release and update Desktop App channel header if needed
- 2.Dev/PM/QA:
- Prioritize reviewing, testing, and merging of pull requests for current release until there are no more tickets in the pull request queue marked for the current release
- Master is tagged and branched and "Release Candidate 1" is cut (e.g. 1.1.0-RC1)
- 3.Marketing:
- Tweet announcement that RC1 is ready
Day when Release Manager and PMs decide which major features are included in the release, and which are postponed.
- 1.Release Manager:
- Post this checklist in Desktop App channel
- Verify all items in the last posted release checklist are complete
- Update Changelog PR based on what’s in/out of the release
- Post a reminder to devs in the Desktop App channel of the code complete date with the ZBB count
- Ask release PM to review the Jira tickets remaining in the current release fix version and push those that won’t make it to the next fix version
- 2.PM:
- Finalize roadmap for next release, and identify planned marketing bullet points
- 3.Marketing:
- Start drafting blog post, tweet, and email for the release announcement
Stabilization period begins when all features for release have been committed. During this period, only bugs can be committed to the release branch. Non-bug pull requests are tagged for the next version.
- 1.Release Manager:
- Post this checklist in Desktop App channel
- Verify all items in the last posted release checklist are complete
- Update meta issue for release in GitHub with a link to the changelog
- 2.Dev:
- Prioritize reviewing, updating, and merging of pull requests for current release until there are no more tickets in the pull request queue marked for the current release
- 1.Release Manager:
- Post this checklist in Desktop App channel
- Verify all items in the last posted release checklist are complete
- Post links to final tickets for next RC to the Desktop App channel
- 2.QA:
- Update Desktop App channel header with links to RC instances and testing spreadsheet
- Post release testing instructions to Desktop App channel with a list of known issues
- Coordinate testing:
- Update the RC Testing Spreadsheet to cover any changes or new features, confirm that known issues are listed in the relevant tests, and assign each area to a team member
- 3.Team:
- Test assigned areas of the Release Candidate Testing spreadsheet
- Daily triage of hotfix candidates and decide whether and when to cut next RC or final
- 4.Dev:
- Submit PRs for hotfixes against the release branch, and review, test and merge prior to next RC
- Push next RC to acceptance and announce in Desktop App channel with new RC link
- 5.Docs:
- Submit Changelog PR for team review
- Submit any remaining documentation PRs for product updates in the release
- 1.Release Manager:
- Post this checklist in Desktop App channel
- Verify all items in the last posted release checklist are complete
- Check that the following are updated in the Changelog:
- Known issues
- Contributors
- Breaking changes
- 2.Team:
- Finish assigned areas of the Release Candidate Testing spreadsheet
- Continue triaging hotfix candidates and decide on whether and when to cut next RC or final
- If no blocking issues are found sign off on the release
- 3.Marketing:
- Finish drafts of art work for Twitter announcement and send to marketing lead for review
The final release is cut. If an urgent and important issue needs to be addressed between major releases, a bug fix release (e.g. 1.1.1) may be created.
- 1.Release Manager:
- Post this checklist in Desktop App channel
- Verify all items in the last posted release checklist are complete
- Merge changelog PR after review is complete
- If there is a security fix, confirm the Changelog recommends upgrade, with a note mentioning the security level and thanking the security researcher
- Draft Mattermost Security Updates if applicable, but do not post until seven days after official release
- Check Security Issues spreadsheet and confirm disclosure text
- Close GitHub meta ticket for the release
- 2.Build:
- Tag a new release (e.g. 1.1.0) and run an official build which should be essentially identical to the last RC
- Post in Desktop App channel with links to all supported distributions and SHA-256 checksum
- Complete code-signing and confirm that it worked well by testing the download links and keeping an eye out for any warnings or issues. Also, use these commands to verify the signatures:
- Windows: On "Developer Command Prompt" (bundled in Visual Studio),
signtool verify /pa /all EXE_TO_VERIFY - Mac: On console,
codesign --verify --deep --strict --verbose=2 Mattermost.app
- 3.Docs:
- Finalize all documentation
- 4.Dev:
- Merge changes made to release branch into master
- 5.Marketing:
- Schedule Twitter announcement for 08:00 PST on the date of marketing announcement
If a bug fix release is required, run through the following steps:
- 1.Dev:
- Submit, review and merge patches for the release branch
- Cut an RC containing all bug fixes
- 2.QA:
- Verify each of the issues in the RC are fixed
- 3.Dev:
- Tag a new release (e.g. 1.1.1) and run an official build including code-signing
- Delete RCs after final version is shipped
- Merge changes made to release branch into master
- 4.Release Manager:
- Update the changelog with notes on patch releases
- Draft Mattermost Security Updates if applicable, but do not post until seven days after official release
- Check Security Issues spreadsheet and confirm disclosure text
- 5.Marketing:
- Schedule Twitter announcement for 08:00 PST on the date of marketing announcement
- 1.Release Manager:
- Post this checklist in Desktop App channel
- Verify all items in the last posted release checklist are complete
- Add new release fix versions in Jira for the next few releases
- Close the release in Jira
- Post key dates for the next release in the header of the Desktop App channel and remove links to RC candidates
- Check for any UserVoice feature suggestions that were completed in the current release
- Confirm marketing has been posted
- Close the release milestone in GitHub
- 2.Dev:
- Delete RCs after final version is shipped
- Check if any libraries need to be updated for the next release
- 1.Release Manager:
- Post this checklist in Desktop App channel
- Update Security Issues spreadsheet with issue number from posted update (e.g. v3.2.0.1)
Last modified 4mo ago