Lets talk conventional commits #5
Description
Discussion
What do you want to talk about?
We have bounced around the idea of using conventional commits in this project.
The positives of this approach is that there is semantic metadata around the nature of a given commit, and there is tooling out there that knows how to understand that metadata and automate things like versioning.
The negative is that it seems a little anti-human to have a bunch of semantic jargon in human readable fields. I can't tell if this is something we would all get used to, but I am sympathetic to that concern.
On the flip side, once you get used to it that jargon does provide information even to our feeble human brains.
There are alternatives to conventional commits, such as gitmoji, which provide a more human (and more concise) value to the commit message. These don't provide the semantic benefit of conventional commits, and so the tooling isn't as robust (might not even exist).
So, lets talk about it.
- Should we move to conventional commits?
- Should we move to something like gitmoji?
- Should we do both?
At the very least we want to identify a standard way to convey semver-relevant information in commits, which is a first class use case of conventional commits.