<type>(<scope>): <subject> <BLANK LINE> <body> <BLANK LINE> <footer>
Where items in angle brackets (
>) are interpreted as "variable" and
will be explained below.
Commits that do not fit this format can not be handled by semv. However, you can configure how semv behaves if it encounters an invalid commit.
Commit parsing is the main way how semv determines a new release version. However, semv allows using additional checks to validate the version increment determined by parsing commits.
New: Starting with version v2.2.0, you can now omit the scope.
type keyword is the most important part for semv. It allows semv to
determine if this should be a minor or patch version increment. In the default
configuration, the type "feat" will trigger a minor release and the types "fix"
and "perf" will trigger a patch release. Other valid types are "chore" (some
clean-up that needed to be done, e.g. to config or something), "test" (adding a
test separately), "docs" (changes to documentation), "ci" (modifications to
continuous integration setup), "refactor", and "style". However, these other
types will not trigger a new version.
Is parsed but not used for determining the new version. However, starting with v2.4.0, semv offers a changelog feature which does use the scope.
Starting with version v2.2.0, you can now omit the scope. As a result, a commit message like "fix: General overhaul" is now valid and will be treated as applying generally in the changelog (starting from v2.4.0).
These are currently only parsed for lines that start with
If any such line is found, semv will trigger a major release.
Which commits are parsed?
In order to determine the next version, all commits since the last version tag (any tag of the form vX.Y.Z) are parsed. If the current commit is a merge commit, then all branches that lead into it are parsed and semv will analyze all commits that are not included in the last version tag. For example
v1.3.1 a ---> b ---> c ---> d \ / \ / e -----------> f
In this case, commit
b was tagged as version v1.3.1. If we call semv on
d, which merges the branch
e->f->d into the "main" branch
a->b->c->c, the semv will analyze commits
Note that this isn't the case by default for python semantic