fix(version_schemes): support arbitrary semver pre-release labels

[bearomorphism]

Description

Fixes #950

This PR fixes a bug where commitizen 3.x raises InvalidVersion (or InvalidVersionPart) when encountering git tags with arbitrary semver pre-release identifiers (e.g., v0.7.1-release, v0.0.1-SNAPSHOT). These are valid semver identifiers per SemVer §9, but the previous regex pattern didn't accept them.

Changes

1. Extended _VERSION_PATTERN regex (version_schemes.py)

The original regex only allowed alpha|beta|preview|rc|a|b|c as pre-release labels. The new pattern adds an additional branch [a-zA-Z-]+ that matches any alphabetical or hyphenated identifier, conforming to semver spec.

Before: (alpha|beta|preview|rc|a|b|c) — only PEP 440 labels accepted
After: (alpha|beta|preview|rc|a|b|c|[a-zA-Z-]+) — also accepts arbitrary labels

2. Widened prerelease parameter type from Prerelease | None to str | None

The Prerelease type alias is Literal["alpha", "beta", "rc"], which is too narrow when the system needs to handle arbitrary labels parsed from existing tags. The CLI still restricts user input to the three known labels; this type widening only affects the internal API.

3. Fixed generate_prerelease() comparison logic

The old code used startswith() to match the incoming prerelease label against the current pre-release phase. This was subtly buggy: "alphabeta".startswith("a") is True, so a label like "alphabeta" would incorrectly be treated as continuing an "alpha" series.

The new logic:

• Normalizes the incoming label using the same mapping packaging uses internally ("alpha"→"a", "beta"→"b", "rc"→"rc", others→lowercase)
• For known PEP 440 labels (a, b, rc): uses max() ordering to prevent down-bumping phases (e.g., won't go from b1 back to a2)
• For arbitrary labels: uses strict equality comparison — no ordering assumptions since arbitrary labels have no defined precedence

This also fixes a potential case-sensitivity issue: "SNAPSHOT" in a tag is normalized to "snapshot" by packaging, so the comparison now lowercases the incoming label for arbitrary labels.

Root Cause Analysis

When commitizen discovers existing tags (e.g., during cz bump), it calls:

Version(tag_string)  →  packaging.version.Version.__init__()
                     →  self._regex.fullmatch(version)

The _regex on BaseVersion was inherited from packaging.version.Version, which only accepts PEP 440 pre-release labels. A tag like v0.7.1-release would fail the regex match and raise InvalidVersion.

By overriding _regex with a pattern that also accepts arbitrary identifiers, the version can be parsed successfully. The rest of the version logic (epoch, release, post, dev, local) remains unchanged.

Test Cases Added

Input Version	Increment	Prerelease	Expected Output
v1.0.0-reallyweird	PATCH	reallyweird	1.0.0-reallyweird1
v0.7.1-release	PATCH	release	0.7.1-release1
v0.0.1-SNAPSHOT	PATCH	SNAPSHOT	0.0.1-snapshot1

AI Disclosure

This PR was revived and updated with AI assistance (GitHub Copilot). The original fix concept came from the community contributor.

[codecov]

⚠️ JUnit XML file not found

The CLI was unable to find any JUnit XML files to upload.
For more help, visit our troubleshooting guide.

[bearomorphism]

I will update this PR this week when I have bandwidth

[bearomorphism]

Maybe we can adjust the workflow. Several PRs got closed just because the target branch is deleted

[Lee-W]

Yep, this was a temporary workflow. we usually don't receive this many PR and don't review this fast. Maybe worth rethink it to make a rc to avoid what we encountered yesterday as well

[bearomorphism]

Updated PR with new description

[Copilot]

Pull request overview

Extends Commitizen’s version parsing to avoid InvalidVersion failures when encountering git tags that use non-PEP440, SemVer-style prerelease labels (e.g., v0.7.1-release, v0.0.1-SNAPSHOT), addressing issue #950.

Changes:

• Widen VersionProtocol.bump() / BaseVersion.bump() prerelease typing from a restricted Literal[...] to str | None.
• Override packaging.version.Version’s parsing regex via BaseVersion._regex to accept additional prerelease labels.
• Add SemVer/SemVer2 test cases to validate bumping with non-standard prerelease labels.

Reviewed changes

Copilot reviewed 4 out of 4 changed files in this pull request and generated 4 comments.

File	Description
commitizen/version_schemes.py	Broadens prerelease typing and overrides the underlying version regex used for parsing.
tests/utils.py	Updates test argument typing to match widened prerelease type (`str
tests/test_version_scheme_semver.py	Adds regression tests for SemVer bumping with arbitrary prerelease labels and v-prefixed tags.
tests/test_version_scheme_semver2.py	Adds a SemVer2 regression test for bumping with an arbitrary prerelease label.

---

💡 Add Copilot custom instructions for smarter, more guided reviews. Learn how to get started.

[bearomorphism]

Addressed. Added equivalent SemVer2 test cases for �0.7.1-release and �0.0.1-SNAPSHOT alongside the existing 1.0.0-reallyweird case.

[bearomorphism]

Good catch. Widened the pattern from [a-z]+? to [a-z]+(?:-[a-z]+)* which now accepts hyphenated labels like pre-release. For labels containing digits (e.g., foo1bar), the regex structure separates the numeric suffix via the pre_n group (foo + 1), which is consistent with how packaging handles it. Purely numeric identifiers like 1.0.0-1 are already handled by the post_n1 group (numeric-only post release). I've updated the PR description to clarify this scoping.

[bearomorphism]

Fixed. The negative lookahead now uses (\+|$) instead of just $, so reserved labels like post and dev are correctly excluded even when followed by a +local segment. Added a test case 1.0.0-release+local123 to verify this.

[bearomorphism]

Addressed. Moved the _regex override from BaseVersion to SemVer (which SemVer2 inherits). Pep440 now retains the strict PEP 440 regex from packaging.version.Version. Added an explicit test test_pep440_rejects_arbitrary_prerelease_labels() to lock this in.