We welcome Github pull requests and issues created by anyone.
In order to contribute code, start by cloning/forking the project from git, and importing it into your IDE.
We require that pull requests:
- Fully describe the intent and use cases for the change
- Have informative commit messages according to these rules
- Separate subject from body with a blank line
- Limit the subject line to 50 characters
- Capitalize the subject line
- Do not end the subject line with a period
- Use the imperative mood in the subject line
- Wrap the body at 72 characters
- Use the body to explain what and why vs. how
- Have unit tests for all non-trivial functionality, where a unit ideally does not span more than one class
- Have grammatically correct PR text
We use Semantic Versioning 2.0 to determine version numbers for releases. Before making a release, decide whether it is a bump in the major, minor or bugfix version:
- MAJOR version when you make incompatible API changes
- MINOR version when you add functionality in a backwards-compatible manner
- BUGFIX version when you make backwards-compatible bug fixes
NOTE: For versions before 1.0, we reserve the right to make API-incompatible changes in any version (but try not to do so).
The release process is as follows:
- Decide which version number to bump (bugfix, minor or major).
- Check out the master branch, and make sure you don't have any local changes.
- Run the following sbt command (substituting
bugfix
as appropriate):
sbt -DBUMP=bugfix "release with-defaults"
- Go to Github's tags page, and fill out release notes
for the new version. The release notes should be a bullet list of the first commit lines of "relevant"
commits in the release. The format is flexible, feel free to summarize where needed. A quick way to get all
the commits is to run
git log [TAG1]..[TAG2] --oneline
.