[Docs] Fix "Conventional Commit" commit message format #3627
Description
GitVersion/docs/input/docs/reference/version-increments.md
Lines 91 to 104 in 63f7d27
The current Conventional Commit configuration breaks the standard's rules. Where
PATCH is supposed to be incremented by only fix or perf, the configuration increments PATCH when the commit Type is any Angular commit Type except feat and no breaking change is present.
Additionally, the following should be noted for consumers:
- In Conventional Commit 1.0.0,
revert-type commits do not explicitly increment the version as their significance differs on a case-by-case basis. The convention gives the following format recommendation:revert: let us never again speak of the noodle incident Refs: 676104e, a215868- WARN: this recommendation prevents commit message analyzers from determining the reverted commit's significance. Analyzers which also parse commit hashes in the message may be able to determine the reverted commit's significance. In contrast, the
angularconvention places the reverted commit's header in the header of the revert commit.
- WARN: this recommendation prevents commit message analyzers from determining the reverted commit's significance. Analyzers which also parse commit hashes in the message may be able to determine the reverted commit's significance. In contrast, the
- Some software used in tandem with GitVersion may use version-increment rules not present in a given commit convention preset (e.g.
angular,conventionalcommits).@semantic-release/commit-analyzerv10.0.1, for example, will incrementPATCHfor anyrevertcommits regardless of the (in)significance of the reverted changes. This semantic-release behavior can be counteracted by adding custom rules to@semantic-release/commit-analyzer's configuration. Rather than RegEx, commit-analyzer uses Micromatch's glob implementation.