The self-managed releases are cut based off of the Mattermost Cloud release tags (e.g Mattermost Server v6.3 release was based off of
cloud-2021-12-08-1 Cloud release tag) in the server, webapp, enterprise, and api-reference repos. See the Handbook release process for more details.
The Mobile and Desktop app release branches are based off of
When your PR is required on a release branch (e.g. for a dot release or to fix a regression for an upcoming release), you will follow the cherry-picking process.
Make a PR to ‘master’ like normal.
Add the appropriate milestone and the
When your PR is approved, it will be assigned back to you to perform the merge and any cherry picking if necessary.
Merge the PR.
An automated cherry-pick process will try to cherry-pick the PR. If the automatic process succeeds, a new PR pointing to the correct release branch will open with all the appropriate labels. If there are no additional changes from the original PR for the cherry-pick, it can be merged without further review.
If the automated cherry-pick fails, the developer will need to cherry-pick the PR manually. Cherry-pick the master commit back to the appropriate releases. If the release branches have not been cut yet, leave the labels as-is and cherry-pick once the branch has been cut. The release manager will remind you to finish your cherry-pick.
CherryPick/Done label when completed.
masterto the affected releases. See the steps below:
Run the checks for lint and tests.
Push your changes directly to the remote branch if the check style and tests passed.
No new pull request is required unless there are substantial merge conflicts.
CherryPick/Approved label and apply the
If conflicts appear between your pull request (PR) and the cherry-pick target branch, the automated cherry-pick process will fail and will let you know that you need to do a manual cherry-pick. Here are the steps to do so:
git fetch origin
git checkout -b manual-cherry-pick-pr-[PR_NUMBER] origin/release-[VERSION]
git log origin/master git cherry-pick [SHA]
git add [path/to/conflicted/files] git cherry-pick --continue
release-[VERSION]as the base branch, and not the default (master).
git push -u origin manual-cherry-pick-pr-[PR_NUMBER]
If you are the second reviewer reviewing a PR that needs to be cherry-picked, do not merge the PR. If the submitter is a core team member, you should set the
Reviews Complete label and assign it to the submitter to cherry-pick. If the submitter is a community member who is not available to cherry-pick their PR or can not do it themselves, you should follow the cherry-pick process above.