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.
lukaszraczylo