We use the GitHub flow for contributions.
- Fork the repository.
- Create a new branch for each feature, fix or improvement.
- Send a pull request from each feature branch to the main branch.
It is very important to separate new features or improvements into separate feature branches, and to send a pull request for each branch. This allow us to review and pull in new features or improvements individually.
All commit messages should adhere to the Conventional Commits specification.
- API relevant changes
feat
Commits, that adds a new featurefix
Commits, that fixes a bug/issue
refactor
Commits, that rewrite/restructure your code, however does not change any API behaviourperf
Commits are specialrefactor
commits, that improve performance
style
Commits, that do not affect the meaning (white-space, formatting, missing semi-colons, etc)test
Commits, that add or correct existing testsdocs
Commits, that affect documentation only- Tooling relevant changes
build
Commits, that affect build components like build tool, dependencies, project version, ...ci
Commits, that affect CI configuration files and scripts
revert
Commits, that revert previous commitschore
Miscellaneous commits without production code change, e.g. modifying.gitignore
Our project adheres to the Semantic Versioning 2.0.0 specification for versioning.
Large refactors breaking the style defined in the .editorconfig
file are frowned upon.
When contributing ensure your code follows existing conventions and styling. (Any issues that arise will be noted in your pull request.)
You must agree that your patch will be licensed under the main license found in this repository, and if we change the license, we will assume that you agreed with the change unless you object to the changes in time.