Fuzzy matching compares each keyword with every word of the commit
message. A word matches if it contains the keyword's letters in order.
Thus "feat" matches "fix(delegation):" and "major" matches
"deps(majors):", which gives false minor and major versions.
The new top-level config key "matching" accepts "fuzzy" (the default)
or "regex". In regex mode every wording keyword is a Go regular
expression. The tool compiles all of them when it loads the config and
runs them against the full commit message, so "(?m)^" anchors a
pattern to the start of a line. An invalid value, an invalid pattern,
or any other config parse error in regex mode stops the tool with a
non-zero exit code. It never falls back to fuzzy matching.
Fuzzy mode does not change. The blacklist check moves into one helper
that both modes use. A replay of 15 repositories gives the same
versions as before. This change improves version precision for the
repositories that opt in.
Claude-Session: https://claude.ai/code/session_01Qq1gbqQek1Zjtofo4VDRdW
Rolling tags like 'v1' (and any other tag that doesn't parse as x.y.z
after prefix stripping) used to enter the latest-tag candidate set in
CalculateSemver. When such a tag shared a commit with a real semver tag
(e.g. v1 and v1.16.3 both pointing at the same release commit), go-git's
alphabetical tag iteration made 'v1' win, ParseExistingSemver bailed out
because '1' has only one component, and the calculator silently reset
the baseline to 0.0.0 — producing nonsense like 0.0.5 on this branch.
ListExistingTags now filters tags through a new IsParseableSemverTag
helper before recording them, so non-semver tags never participate in
latest-tag selection. The behavior change is invisible for repos that
only use proper vX.Y.Z tags, and it's covered by a new test table.
This feature can be useful for repositories with already established versioning, but
having hundreds of commits which could potentially produce really weird results due
to lack of previous rules on wording.