prerelease can't comply with the semver.org specification

[nweldev]

Commitizen only implements the normalized PEP-440 prerelease format, excluding separators between :

• the release segment and the pre-release segment
• the pre-release signifier and the numeral

Therefore, when using the bump command, we can't define a version format which complies with the one defined by the semver.org specification :

"pre-release version MAY be denoted by appending a hyphen and a series of dot separated identifiers immediately following the patch version."

"Examples: 1.0.0-alpha, 1.0.0-alpha.1, 1.0.0-0.3.7, 1.0.0-x.7.z.92."

consequences

cz bump can't be used for prereleases alongside tools that follow this specification.

Especially, this leads to an error when using the Node.js semver package.

Yet, this package is used by a bunch of other tools, like Github Automatic Release (see error message below) and conventional-changelog.

The parameter "automatic_release_tag" was not set and the current tag "v1.0.0rc1" does not appear to conform to semantic versioning.
(node:3557) UnhandledPromiseRejectionWarning: Error: The parameter "automatic_release_tag" was not set and the current tag "v1.0.0rc1" does not appear to conform to semantic versioning.
  at /home/runner/work/_actions/marvinpinto/action-automatic-releases/latest/dist/index.js:1:224465
  at Generator.next (<anonymous>)
  at /home/runner/work/_actions/marvinpinto/action-automatic-releases/latest/dist/index.js:1:221749
  at new Promise (<anonymous>)
  at n (/home/runner/work/_actions/marvinpinto/action-automatic-releases/latest/dist/index.js:1:221494)
  at /home/runner/work/_actions/marvinpinto/action-automatic-releases/latest/dist/index.js:1:224406
  at /home/runner/work/_actions/marvinpinto/action-automatic-releases/latest/dist/index.js:1:224971
  at Generator.next (<anonymous>)
  at /home/runner/work/_actions/marvinpinto/action-automatic-releases/latest/dist/index.js:1:221749
  at new Promise (<anonymous>)

details

When adding a hyphen between patch and release in the configuration, it appears in all version numbers, including not prerelease ones (e.g. v1.2.3- instead of v1.2.3).

tag_format = "v$minor.$major.$patch-$prerelease"

In addition, there doesn't seem to be any way to add a separator (dot) between the prerelease signifier and the numeral.

[woile]

Thanks for reporting this issue. The main problem, I think, arises because we are using PEP0440 for anything else than the mandatory parts of the version.

In order to fix this properly, I think we should move fully to a semver package. But this will be scheduled for 2.0 to avoid breaking compatibility.
I'm working on the changelog, and once that's done we'll push for this.

Regards!

[nweldev]

Thx @woile!

FYI, for now, my workaround is to add a semver.org compliant tag after having run cz bump -pr <x>.

So, for example :

cz bump -pr rc --increment MAJOR
git tag v1.0.0-rc.0 v1.0.0rc0
git push --follow-tags

This is because cz requires the normalized PEP-404 format when the node.js semver package requires the other, but for tags only (in my case).

[woile]

I've run some tests and semver from poetry will be useful:

In [1]: from semver.version import Version                                                                                                       

In [3]: v = Version.parse("1.0.0-alpha")                                                                                                         

In [7]: v.__dict__                                                                                                                               
Out[7]: 
{'_major': 1,
 '_precision': 3,
 '_minor': 0,
 '_patch': 0,
 '_rest': 0,
 '_text': '1.0.0-alpha',
 '_prerelease': ['alpha', 0],
 '_build': []}

In [8]: v = Version.parse("1.0.0-a0")                                                                                                            

In [9]: v                                                                                                                                        
Out[9]: <Version 1.0.0-a0>

In [10]: v.__dict__                                                                                                                              
Out[10]: 
{'_major': 1,
 '_precision': 3,
 '_minor': 0,
 '_patch': 0,
 '_rest': 0,
 '_text': '1.0.0-a0',
 '_prerelease': ['alpha', 0],
 '_build': []}

In [11]: v = Version.parse("1.0.0a0")                                                                                                            

In [12]: v.__dict__                                                                                                                              
Out[12]: 
{'_major': 1,
 '_precision': 3,
 '_minor': 0,
 '_patch': 0,
 '_rest': 0,
 '_text': '1.0.0a0',
 '_prerelease': ['alpha', 0],
 '_build': []}

It will be some work to refactor, but doable.

[yajo]

I personally like more PEP440. Although it has less hype, it has some features semver lacks.

Wouldn't it make sense to configure commitizen's versioning scheme? There are more already, and nobody knows which will be world's favorite tomorrow...

Note: in one project I run, we were using semver before, and we switched to PEP440 later. IMHO if a tag doesn't fit into the chosen versioning schema, commitizen shouldn't die. It should just skip it.

[nbrugger-tgm]

Is there a workaround besides forking the repo and customizing the code to my needs?
(if semver is enforced)

[asafdl]

I see this has been opened for 2 years, is there any way to configure the regex that decides which prerelease is acceptable?

[woile]

Unfortunately I haven't had time to work on this, and I've just recently started working on this. But I do want to have it, because it will play well with tools that use semver like rust ecosystem or helm charts.
There's no pattern, we were relying on the version system from python.

[sanslash332]

hello @woile
Any news about this issue? is scheduled for the future implement full-semver?

Or atmost a method to add the dash (-) on the tag_format just when prereleace is present? and a method to add custom prereleases keywords?

And thanks. Is hard find a tool that concider all versioning cases. For our needs we droped various other tools before, and commitizen aparently is the tool that best fit into our needs; excepting for these small drawbacks.

[woile]

I know, and I apologize, I just haven't had the bandwith. My intention is still to add semver. The tool I was considering before was deprecated. But there's another one I found semver

[AliSajid]

Just adding my voice to this. I build small rust applications and automating the release with commitizen has been very helpful This will make my life so much easier.

[woile]

This has been released with v3.
Check the docs:

https://commitizen-tools.github.io/commitizen/bump/#version_type

More info on the release page:
https://github.com/commitizen-tools/commitizen/releases/tag/3.0.0

For rust users, the version provider might also be interesting. Commitizen can use the version on cargo as the source of truth