Presenter uses semantic release to maintain semantic versioning.
This means that your commits must identify what changes are in them. Examples (from the semantic release readme):
| Commit message | Release type |
|---|---|
fix(pencil): stop graphite breaking when too much pressure applied |
Patch Release |
feat(pencil): add 'graphiteWidth' option |
|
perf(pencil): remove graphiteWidth optionBREAKING CHANGE: The graphiteWidth option has been removed.The default graphite width of 10mm is always used for performance reasons. |
The following types are available:
- feat: A new feature
- fix: A bug fix
- docs: Documentation only changes
- style: Changes that do not affect the meaning of the code (white-space, formatting, missing semi-colons, etc)
- refactor: A code change that neither fixes a bug nor adds a feature
- perf: A code change that improves performance
- test: Adding missing or correcting existing tests
- chore: Changes to the build process or auxiliary tools and libraries such as documentation generation
The Angular Git Commit Guidelines outlines the conventions in full detail.
-
Ensure the bug was not already reported by searching on GitHub under Issues.
-
If you're unable to find an open issue addressing the problem, open a new one. Be sure to include a title and clear description, as much relevant information as possible, and a code sample or an executable test case demonstrating the expected behavior that is not occurring.
-
Use the bug report templates to create the issue.
-
Open a new GitHub pull request with the patch.
-
Ensure the PR description clearly describes the problem and solution. Include the relevant issue number if applicable.
- Suggest your change as a new feature request and start writing code.
- Ask any question about how to use Presenters open a support/question
- Open a new GitHub pull request with the patch.
Presenters are a volunteer effort. We encourage you to pitch in and join the team!
Thanks! ❤️ ❤️ ❤️
Presenters Team
(Attribution: Adapted from Rails contribution guidlines)