All work on MBT happens directly on GitHub. Both core team members and external contributors send pull requests which go through the same review process.
We will do our best to keep the master branch in a good shape, with tests passing at all times. But in order to move fast, we will make API changes that your application might not be compatible with. We recommend that you use the latest stable version of MBT.
If you send a pull request, please do it against the
We maintain stable branches for major versions separately but we don’t accept pull requests to them directly.
Instead, we cherry-pick non-breaking changes from master to the latest stable major version.
MBT follows semantic versioning. We release patch versions for bug-fixes, minor versions for new features, and major versions for any breaking changes. When we make breaking changes, we also introduce deprecation warnings in a minor version so that our users learn about the upcoming changes and migrate their code in advance. Every significant change will be documented in the changelog file.
Sending a Pull Request
The team is monitoring for pull requests. We will review your pull request and either merge it, request changes to it, or close it with an explanation.
Before submitting a pull request, please make sure the following is done:
- Fork the repository and create your branch from master.
go mod vendorin the repository root.
- If you’ve fixed a bug or added code that should be tested, add tests!
- See commit prefix section
- Ensure the test suite passes via
go test -v ./...Tip: you can use command
- You can test the binary by using command
makewhich will build the binary for each target OS.
- If you change some config file you should run
go generatecommand, this will create equivalent byte content file.
- Format your code with
go fmtand run linter or better use
make linton your changes.
- If you haven’t already, complete the CLA.
- [feat] (new feature for the user, not a new feature for build script)
- [fix] (bug fix for the user, not a fix to a build script)
- [docs] (changes to the documentation)
- [style] (formatting, missing semi colons, etc; no production code change)
- [refactor] (refactoring production code, eg. renaming a variable)
- [test] (adding missing tests, refactoring tests; no production code change)
- [chore] (updating grunt tasks etc; no production code change)