Core Developer Handbook¶
This handbook contains documentation useful for Mattermost core developers. A core developer is a maintainer on the Mattermost project that has merge access to the Mattermost repositories. They are responsible for reviewing pull requests, cultivating the Mattermost developer community and guiding the technical vision of Mattermost.
Come join our “Contributors” community channel on our daily build server, where you can discuss questions with community members and the Mattermost core team. Join our “Developers” channel for technical discussions and our “Integrations” channel for all integrations and plugins discussions.
Current Core Developers¶
Below is the list of core developers working on Mattermost:
- Corey Hulen
- Joram Wilander
- Christopher Speller
- Harrison Healey
- Elias Nahum
- George Goldberg
- Saturnino Abril
- Chris Duarte
- Carlos Panato
- Martin Kraft
- Jesús Espino
- Jesse Hallam
- Sudheer Timmaraju
Below is the list of core developers working on individual Mattermost repositories:
Technical Development Goals¶
We discuss these goals every other week during the weekly developer meeting.
- Performance for 20,000 daily active users (complete)
- React Native mobile apps (complete)
- Performance for 200,000 daily active users, 200 million messages per month
- Developer Toolkit (APIs, plugins, integrations, samples, documentation)
Reviewing & Merging Pull Requests¶
Core developers are expected to code review pull requests submitted to the Mattermost repositories. Below are some guidelines for reviewing code:
- Responsibility for the submitted code relies on the submitter, it is their responsibility to test and implement any changes at high quality. As a result, code reviewers are not required to do a full audit of code changes but should read through the code to:
- Make sure the implementation matches the description of the ticket being completed
- Ask questions about anything that is not clear
- To request changes when the code looks incorrect or doesn’t match the correct design patterns
- Stable respositories that have had a 1.0.0 release require two approved reviews before the changes can be merged
- Unstable repositories that are still in development may be merged with a single approved review
- Trivial changes, such as PM-approved text changes or typo fixes, maybe merged with only a single approved review for both stable and unstable repositories
Release Cutting Process¶
Note: To cut a build you need access to matterbuild. Please ask Christopher for access if you don’t have it.
On code complete day, work with the PM on rotation to get all the pull requests for the current release merged into
master. Once that is done and you’ve confirmed with the PM, cut the first release candidate by following these steps:
- Submit a PR to uncomment the upgrade code for the release version and add it to the version array. Use these PRs as examples, https://github.com/mattermost/mattermost-server/pull/6336/files and https://github.com/mattermost/mattermost-server/pull/6600/files.
- Once the above PR is merged, post
/mb cut X.X.X-rc1into a private channel. Replace
X.X.Xwith the release version, ex:
3.10.0. This will begin cutting the build and make an automatic post to the Release Discussion channel.
- Wait approximately 40 minutes for the build to finish. If the build fails, you will need to delete the version tags from the mattermost-server, mattermost-webapp and enterprise repositories by running
git push origin :vX.X.X-rc1in all of them. Then simply repeat step 2. You can monitor build status from https://build.mattermost.com.
- Once the build finishes, submit a PR to
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 replace 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:
- Must be for Jira tickets approved for this release by you and the PM on rotation.
- Should be assigned to you and have the correct milestone set.
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,
- Wait for the build to finish, deleting tags (
git push origin :X.X.X-rcX) and re-running if the build fails.
Again, the build automation will update all the servers and post in the Release Discussion channel.
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.
- Just like before, if the build fails you can delete the tags and re-run it.
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.
/mb setprerelease masterinto a private channel.