Description

Closes #1614.

Why

When a project uses version_scheme = "semver2" together with a custom tag_format that includes ${prerelease} — for example "${major}.${minor}-${patch}${prerelease}" — the tags that commitizen creates (e.g. 0.0-2rc.0) cannot be recognised on the next invocation. Every subsequent cz bump --prerelease rc prints Invalid version tag: '0.0-2rc.0' does not match any configured tag format and then exits with code 16, making it impossible to chain prerelease bumps without manually running cz changelog in between.

The culprit is the prerelease entry in get_tag_regexes (commitizen/defaults.py:159). The old pattern r"(?P<prerelease>\w+\d+)?" requires the prerelease segment to end with a decimal digit — matching PEP-440 forms like rc0 or alpha1, but not SemVer2 forms like rc.0 or alpha.beta.1 (the dot terminates \w+, and the mandatory \d+ then fails to match .0). Commitizen itself generates the SemVer2 form when version_scheme = "semver2" is active, so the tag it just wrote is immediately unreadable by the regex that should recognise it.

Triage in #1964 reproduced the exact failure against master (v4.15.1): after cz bump --prerelease rc --yes, git tag --list shows 0.0-2rc.0; the following cz bump --prerelease rc --yes fails as described. A related defect in the devrelease regex — it required a leading dot (\.dev\d+) while the ${devrelease} substitution can produce the dot-less form dev1 in some tag formats — is fixed in the same change, as both regexes live side-by-side in get_tag_regexes.

What changed

How it works

• get_tag_regexes (commitizen/defaults.py:151–165) returns a dict that maps tag-format placeholders like ${prerelease} to named-capture-group regex fragments. Those fragments are assembled into a full tag-matching regex elsewhere in the tag-parsing pipeline.
• prerelease change — \w+(?:\.\w+)* replaces \w+\d+. The old suffix \d+ forced the token to end with a digit: rc0 ✓, rc.0 ✗. The new pattern is an initial \w+ segment (matching rc, alpha, dev) followed by zero or more .\w+ repetitions (matching .0, .beta, .1), making it greedy enough for multi-segment SemVer2 prereleases (alpha.beta.1) without over-matching. The whole group remains optional (?) so plain releases continue to match.
• devrelease change — \.?dev\d+ replaces \.dev\d+. The leading dot is optional so that ${devrelease} substitutions that omit the dot separator (see Tag not set correctly using devreleases with semver2 and custom tag_format #1615) still round-trip correctly. The literal dev prefix is preserved — a bare \d+ suffix without it would let the regex match arbitrary numeric noise.
• Why not [^\s+]* for prerelease? That would be too permissive — it would consume literal characters from adjacent placeholders or from structural separators in the tag_format string (e.g. a + used for build metadata), corrupting the overall tag regex.
• Why not fix normalize_tag instead? The tag format chosen in the issue (${major}.${minor}-${patch}${prerelease}) is valid; the tag string 0.0-2rc.0 is what commitizen correctly produces for version 0.0.2-rc.0 under that format. The bug is purely in the regex used to re-read those tags — widening the regex is the minimal, safe fix.

Backward compatibility

• \w+\d+ is a strict subset of \w+(?:\.\w+)*: every tag string matched by the old regex is still matched by the new one. No previously-valid tag is rejected.
• The optional whole-group ? is preserved for both prerelease and devrelease, so plain version tags (no prerelease, no devrelease) continue to match without changes.
• All existing tests in test_tags.py, test_bump_normalize_tag.py, test_changelog.py, and test_bump_command.py still pass.
• The change is internal to get_tag_regexes; no public API or config key is altered.

Checklist

• I have read the contributing guidelines

Was generative AI tooling used to co-author this PR?

• Yes (please specify the tool below)

Generated-by: Claude following the guidelines

Code Changes

• Add test cases to all the changes you introduce
• Run uv run poe all locally to ensure this change passes linter check and tests
• Manually test the changes (see "Steps to Test" below)
• Update the documentation for the changes

Expected Behavior

Steps to Test This Pull Request

git fetch fork fix/1614-prerelease-regex-allow-dots
git checkout fork/fix/1614-prerelease-regex-allow-dots

# 1. Targeted regression test.
uv run pytest tests/test_tags.py::test_is_version_tag_accepts_semver2_prerelease_in_custom_tag_format -v

# 2. Reproduce the bug, then verify the fix.

mkdir /tmp/cz1614 && cd /tmp/cz1614
git init -b main
git config user.name test && git config user.email [email protected]

cat > cz.toml << 'EOF'
[tool.commitizen]
name = "cz_conventional_commits"
tag_format = "${major}.${minor}-${patch}${prerelease}"
version_scheme = "semver2"
version = "0.0.1"
update_changelog_on_bump = true
EOF

echo "# test" > README.md
git add README.md cz.toml
git commit -m "fix: initial commit"

# First prerelease bump — creates tag 0.0-2rc.0
cz bump --prerelease rc --yes

# Add another commit
echo "change" >> README.md && git add README.md
git commit -m "fix: add changes"

# Second bump — failed before this fix with "Invalid version tag" error.
# After the fix: succeeds and creates 0.0-2rc.1.
cz bump --prerelease rc --yes

# Changelog — emitted warnings before; should be clean now.
cz changelog --dry-run

Additional Context

This is one of three bugs surfaced by the triage audit in #1964. The devrelease half of this fix is closely related to #1615, which addresses the companion issue where ${devrelease} substitution itself produced the wrong form; both defects share the same get_tag_regexes function (commitizen/defaults.py:151–165) as their root.