René's URL Explorer Experiment

Title: fix(tags): widen prerelease and devrelease tag regexes for SemVer2 by bearomorphism · Pull Request #1972 · commitizen-tools/commitizen · GitHub

Open Graph Title: fix(tags): widen prerelease and devrelease tag regexes for SemVer2 by bearomorphism · Pull Request #1972 · commitizen-tools/commitizen

X Title: fix(tags): widen prerelease and devrelease tag regexes for SemVer2 by bearomorphism · Pull Request #1972 · commitizen-tools/commitizen

Description: 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\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 File Change commitizen/defaults.py Widened prerelease regex from \w+\d+ to \w+(?:\.\w+)* and made the leading dot in devrelease optional (\.?dev\d+) inside get_tag_regexes (lines 159–160) tests/test_tags.py Added test_is_version_tag_accepts_semver2_prerelease_in_custom_tag_format — regression test asserting is_version_tag accepts 0.0-2rc.0, 0.0-2, and 0.0-2alpha.beta.1 with the custom tag format from the issue 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 #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 Scenario Outcome cz bump --prerelease rc with version_scheme = "semver2" and tag_format containing ${prerelease} Succeeds; no Invalid version tag warnings on subsequent bumps cz changelog --dry-run after creating a SemVer2 prerelease tag Renders the release without warnings Multi-segment prerelease alpha.beta.1 in a custom tag_format Recognised and round-tripped correctly Plain version tag (no prerelease) Matched as before — the ? quantifier is preserved Tag with PEP-440-style prerelease (rc0, alpha1) Still matched — \w+ with no dot segments covers these 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 test@test.com 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.

Open Graph Description: 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}${...

X Description: Description Closes #1614. Why When a project uses version_scheme = &quot;semver2&quot; together with a custom tag_format that includes ${prerelease} — for example &quot;${major}.${minor...

Opengraph URL: https://github.com/commitizen-tools/commitizen/pull/1972

X: @github

direct link

Domain: github.com

Links:

Viewport: width=device-width