You are encouraged to contribute to the repository by forking and submitting a pull request.
(If you are new to GitHub, you might start with a basic tutorial and check out a more detailed guide to pull requests.)
Pull requests will be evaluated by the repository guardians on a schedule and if deemed beneficial will be committed to the main branch. Pull requests should have a descriptive name and include an summary of all changes made in the pull request description.
If you would like to propose a significant change, please open an issue first to discuss the proposed changes with the community and to avoid re-work.
Contributions are made pursuant to the Developer's Certificate of Origin, available at https://developercertificate.org, and licensed under the Apache License, version 2.0 (Apache-2.0).
- It is difficult to manage a release with too many changes.
- We should release more often, not months apart.
- We should focus on feature releases (minor and patch releases) to speed iteration.
- See our Credo Docs on semantic versioning. Notably, while our versions are pre 1.0.0, minor versions are breaking change versions.
- Mixing breaking changes with other PRs slows development.
- Non-breaking change PRs are merged earlier into main
- Breaking change PRs will go to a branch named -pre (ie. 0.3.0-pre) and merged later in the release cycle.
- Consider separating your PR into a (usually larger) non-breaking PR and a (usually smaller) breaking change PR.
- Commits and PR titles MUST follow conventional commits (https://www.conventionalcommits.org/en/v1.0.0/). This allows us to automatically determine the next release version and generate changelog files.
- Use conventional commits to mark breaking changes. Adding
!after the scope of a prefix message (e.g.chore!: a breaking change) or adding a BREAKING CHANGE: note to commit messages marks a commit as breaking. See examples: https://www.conventionalcommits.org/en/v1.0.0/#examples
- Use conventional commits to mark breaking changes. Adding