"The Conventional Commits specification is a lightweight convention on top of commit messages. It provides an easy set of rules for creating an explicit commit history; which makes it easier to write automated tools on top of. This convention dovetails with SemVer, by describing the features, fixes, and breaking changes made in commit messages."
https://www.conventionalcommits.org/en/v1.0.0/
I find that the pull request template could be improved. A lot of the time the only choice is to mark stuff as [DOCS] when a lot of the time it really is something else.
https://github.com/apache/sedona/blob/master/.github/pull_request_template.md
So this task if approved would be to also update the contributing guides and pull request template etc
Why Use Conventional Commits
- Automatically generating CHANGELOGs.
- Automatically determining a semantic version bump (based on the types of commits landed).
- Communicating the nature of changes to teammates, the public, and other stakeholders.
- Triggering build and publish processes.
- Making it easier for people to contribute to your projects, by allowing them to explore a more structured commit history.
"The Conventional Commits specification is a lightweight convention on top of commit messages. It provides an easy set of rules for creating an explicit commit history; which makes it easier to write automated tools on top of. This convention dovetails with SemVer, by describing the features, fixes, and breaking changes made in commit messages."
https://www.conventionalcommits.org/en/v1.0.0/
I find that the pull request template could be improved. A lot of the time the only choice is to mark stuff as
[DOCS]when a lot of the time it really is something else.https://github.com/apache/sedona/blob/master/.github/pull_request_template.md
So this task if approved would be to also update the contributing guides and pull request template etc
Why Use Conventional Commits