Help wanted: commitizen 3.x not supoort generate CHANGELOG with tag format like v1.0.0-release

Description

Commitizen 3.x not supoort generate CHANGELOG with tag format like v1.0.0-release, but it works well with commitizen 2.x.

My repo tags could not be changed as it released. Any idea to solve this problem in order to generate the changelog correctly?

Steps to reproduce

PS E:\codes\aidi-sdk> cz ch                           
InvalidVersion GitTag('v0.7.1-release', '0689497d1cf9d036cb510cfed3a96135d9456419', '2023-12-08')
InvalidVersion GitTag('v0.7.0-release', 'c81dd1acd809ea2df66154bc5ecb64fb625a40e6', '2023-12-07')

Current behavior

no

Desired behavior

no

Screenshots

No response

Environment

cz version: 3.13.0

This is also happening for maven type versions (using cz version 3.13.0):

cz init
Welcome to commitizen!

Answer the questions to configure your project.
For further configuration visit:

https://commitizen-tools.github.io/commitizen/config/

? Please choose a supported config file:  .cz.toml
? Please choose a cz (commit rule): (default: cz_conventional_commits) cz_conventional_commits
? Choose the source of the version: commitizen: Fetch and set version in commitizen config (default)
? Is master_0.0.2-SNAPSHOT.74 the latest tag? No
? Please choose the latest tag:  v0.0.1-SNAPSHOT
? Choose version scheme:  semver
Traceback (most recent call last):
  File "/usr/local/bin/cz", line 8, in <module>
    sys.exit(main())
             ^^^^^^
  File "/usr/local/Cellar/commitizen/3.13.0/libexec/lib/python3.12/site-packages/commitizen/cli.py", line 570, in main
    args.func(conf, arguments)()
  File "/usr/local/Cellar/commitizen/3.13.0/libexec/lib/python3.12/site-packages/commitizen/commands/init.py", line 100, in __call__
    version = get_version_scheme(self.config, version_scheme)(tag)
              ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
  File "/usr/local/opt/python-packaging/lib/python3.12/site-packages/packaging/version.py", line 200, in __init__
    raise InvalidVersion(f"Invalid version: '{version}'")
packaging.version.InvalidVersion: Invalid version: 'v0.0.1-SNAPSHOT'

Thanks for reporting. Just verified this is a valid issue.

@noirbizarre

The root cause is

commitizen/commitizen/version_schemes.py

Line 152 in ac07bda

class BaseVersion(_BaseVersion):

. The following is a simplified version of this error.

from packaging.version import Version as _BaseVersion

_BaseVersion("1.0.0-test")

I guess we'll need to overwrite https://github.com/pypa/packaging/blob/32deafe8668a2130a3366b98154914d188f3718e/src/packaging/version.py#L185 to something like https://github.com/pypa/packaging/blob/32deafe8668a2130a3366b98154914d188f3718e/src/packaging/version.py#L117 but with semver support?

@noirbizarre @woile WDYT?

Definitely a good idea, we should add tests for semver and semver2

Added tests first #1081

fix: fix bumping version functionality by removing changelog function…

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

Triage from #1964: This is a config issue, not a bug. Tags like v1.0.0-release need a matching tag_format = "v$version-release" (or use legacy_tag_formats for old tags). Without that, commitizen can't extract a version from the tag — hence the InvalidVersion warning. Suggesting we close this.

Verification update (re #1964)

Reproduced against current master (4.15.1):

Test A — default tag_format = "v$version" with manually-created tags v0.7.0-release and v0.7.1-release:

## Unreleased

### Feat

- new

No InvalidVersion warnings, but the suffixed tags are silently ignored (treated as not-version tags) and don't appear as release headings.

Test B — tag_format = "v$version-release" (matching the actual tag pattern):

## Unreleased

### Feat

- new

## v0.7.0-release (2026-05-09)

Tags are recognized correctly, no warnings.

Verdict: NOT A BUG / CONFIG-ONLY.

Two notes:

The original report's InvalidVersion ... v0.7.1-release warnings don't reproduce on current master with the default tag_format. The current TagRules warns on tags that look like versions but don't match (good UX), and silently skips ones that don't look like versions at all.
Setting tag_format = "v$version-release" (or legacy_tag_formats = ["v$version-release"] if mixing tag styles) makes the suffix-tags work as expected.

Closing-eligible with a short response pointing the user to the matching tag_format.

Closing as config issue: setting tag_format = "v\$version-release" (or adding it to legacy_tag_formats) makes the suffix tags work correctly. See verification comment above. Reopen if the matching tag_format doesn't work for your case.

Navigation Menu

Repository navigation

Help wanted: commitizen 3.x not supoort generate CHANGELOG with tag format like v1.0.0-release #950

Description

Steps to reproduce

Current behavior

Desired behavior

Screenshots

Environment

Metadata

Assignees

Labels

Type

Projects

Milestone

Relationships

Development

Help wanted: commitizen 3.x not supoort generate CHANGELOG with tag format like v1.0.0-release #950

Description

Description

Steps to reproduce

Current behavior

Desired behavior

Screenshots

Environment

Activity

rshmhrj commented on Jan 17, 2024

Lee-W commented on Apr 23, 2024

Lee-W commented on Apr 23, 2024

woile commented on Apr 23, 2024

Lee-W commented on Apr 24, 2024

bearomorphism commented on May 9, 2026

bearomorphism commented on May 9, 2026

bearomorphism commented on May 9, 2026

Metadata

Metadata

Assignees

Labels

Type

Projects

Milestone

Relationships

Development

Issue actions