Note: To cut a build you need access to matterbuild. Please ask Christopher/Jason/Elisabeth for access if you don’t have it.
Developers and PMs decide when to create the release branch. The branch can be created from master or from an existing release branch, depending on which type of release we are planning. If it is a Quality Release, the new branch should be branched off the previous release, otherwise the branch should be off the master branch.
All commits go to master branch and are then cherry-picked to the appropriate branch. Commits to master follow the PR process and once the PR is approved and merged, the developer should cherry-pick that commit to the appropriate branch. No PR is needed for cherry-picks.
On code complete day, work with the PM on rotation to get all the pull requests for the current release merged into
master and cherry-picked to the correct branch. Once that is done and you’ve confirmed with the PM, cut the first release candidate by following these steps:
/mb cut X.X.X-rc1into a private channel. Replace
X.X.Xwith the release version, ex:
5.8.0. This will begin cutting the build and make an automatic post to the Release Discussion channel.
backportflags in order to trigger the old job, ie.
/mb cut 5.7.1-rc1 --backport --legacy.
/mb cut 5.8.0-rc1 --server mattermost/mattermost-build-server:dec-7-2018 --webapp mattermost/mattermost-build-webapp:oct-2-2018.
Community Server) or Jason Deland (
RCX, for example
5.8.0-rc2(for example) to deploy the RC in the
masterto add the upgrade code for the next release. For example, https://github.com/mattermost/mattermost-server/pull/6337/files and https://github.com/mattermost/mattermost-server/pull/6616/files.
The build automation will take care of updating all the CI and test servers, and it will make a post in the Release Discussion channel with all the download links. It will also create the release branch named
X-X replaced by the major and minor version numbers.
Between now and the final release being cut, work with the PM on rotation to get priority fixes merged into the release branch. Note that all PRs to the release branch:
Work with the PM on rotation to decide when to cut new release candidates. The general guideline is cut a new RC after 3-5 fixes have been merged or it’s been a day or two since any more issues have come up. Each release usually has 3-4 release candidates. To cut a new release candidate:
/mb cut X.X.X-rcXinto a private channel, replacing
X.X.X-rcXwith the release version and the release candidate number we’re on. For example,
Again, the build automation will update all the servers and post in the Release Discussion channel.
In addition to cutting new release candidates, you should merge the release branch into master on a daily basis. You can do this by making a pull request to merge
When it’s time to cut the final build, confirm with the PM that no more changes need to be merged. To cut the final release:
/mb cut X.X.Xinto a private channel, replacing
X.X.Xwith the release version.
The links to download the final build will be posted in the Release Discussion channel. Congratulations, you’ve cut a release!
After a couple days pass you will need to set the CI servers to point back to
master. To do this:
/mb setci masterinto a private channel.