I follow the Conventional Commit standard, because it allows me to automate Semantic Versioning in CI pipelines.
Examples:
Added a new CLI command? $ git commit -m "feat: add foo command" && git push then CI tests, builds, and increments MINOR version 1.0.9 -> 1.1.0, and publishes artifacts.
Fixed a race condition bug? $ git commit -m "fix: fix race condition" && git push then CI tests, builds, and increments PATCH version 1.1.0 -> 1.1.1, and publishes artifacts.
If a feature or bug fix is non-backward compatible, then add BREAKING CHANGE in git commit message, which will lead to incrementing the MAJOR version 1.1.1 -> 2.0.
If any change needs some context (eg why the change was made), I add it in the commit message body. More often, I reference the ticket or issue in bug tracker, like:
I follow the Conventional Commit standard, because it allows me to automate Semantic Versioning in CI pipelines.
Examples:
Added a new CLI command?
$ git commit -m "feat: add foo command" && git push
then CI tests, builds, and increments MINOR version1.0.9
->1.1.0
, and publishes artifacts.Fixed a race condition bug?
$ git commit -m "fix: fix race condition" && git push
then CI tests, builds, and increments PATCH version1.1.0
->1.1.1
, and publishes artifacts.If a feature or bug fix is non-backward compatible, then add
BREAKING CHANGE
in git commit message, which will lead to incrementing the MAJOR version1.1.1
->2.0
.If any change needs some context (eg why the change was made), I add it in the commit message body. More often, I reference the ticket or issue in bug tracker, like:
This looks interesting. I should look this up soon. Maybe I can reach out to you, if I need some help.
I like this, I'm curious, do you use something automated to handle your semantic versioning like this?
I use semantic-release for all my projects. I like it because it is language-agnostic.
semantic-release
CLI in CI.