@P1ng-W1n thanks for your bug report - you're right. According to SemVer 2.0.0, version 0.1.0-0f is valid - https://semver.org/#is-there-a-suggested-regular-expression-regex-to-check-a-semver-string

Thanks for the confirmation..
I checked this further, and it seems that any floating number (^0[0-9][a-f]*) would trigger this issue.
This also means that people who would like to use their git commit hash as part of the prerelease version have a 1/16 chance to fail on this validation

Thanks for your report! 👍

Well, I'm not so sure. According to the provided link, version 0.1.0-0f would be indeed valid. However, when using something like version 0.1.0-01, this would lead to a traceback and marked as invalid.

If I read the Backus–Naur Form Grammar for Valid SemVer Versions correctly, the pre-release cannot start with a digit. Here is the relevant part from the spec:

<pre-release> ::= <dot-separated pre-release identifiers>

<dot-separated pre-release identifiers> ::= <pre-release identifier>
                                          | <pre-release identifier> "." <dot-separated pre-release identifiers>

<build> ::= <dot-separated build identifiers>

<dot-separated build identifiers> ::= <build identifier>
                                    | <build identifier> "." <dot-separated build identifiers>

<pre-release identifier> ::= <alphanumeric identifier>
                           | <numeric identifier>

<alphanumeric identifier> ::= <non-digit>
                            | <non-digit> <identifier characters>
                            | <identifier characters> <non-digit>
                            | <identifier characters> <non-digit> <identifier characters>

It seems, this is the correct behavior, right?

@P1ng-W1n If you really need commit hashes in your pre-release, you need to use a character as a prefix, for example 0.1.0-sha01 would be valid.

Hmm.. Right.. The semver description is a little bit misleading. Section 9 states that:

Numeric identifiers MUST NOT include leading zeroes.

This truly makes 0.1.0-01 invalid (as that's clearly a number), but would also invalidate 0.1.0-0abcdef (which -I would argue- isn't a number).
Considering that prerelease and build metadata can contain ASCII alphanumerics, so I'm not sure if it's wise to interpret them anything else than strings.

Thanks for having a deeper look into the Semver spec. 👍

If I'm not mistaken, the semver library is then in accordance to the specification. To avoid such problems, the only solution I can see is to add a non-digit prefix for the pre-release, like c for commits or sha.

it's wise to interpret them anything else than strings.

That's correct. The semver library interpretes pre-release and build parts always as strings.

Ok.. After a second (and third) reread of the referenced specification I can't see any other way to solve this either.

Although I'm a little bit puzzled why that rule is in place when it comes to string type values (pre-release version), but that's more of a question related to the specification I feel.

Thanks for your quick response.

Ok.. After a second (and third) reread of the referenced specification I can't see any other way to solve this either.

Thanks for confirming. 👍

Although I'm a little bit puzzled why that rule is in place when it comes to string type values (pre-release version), but that's more of a question related to the specification I feel.

Mee too! I don't know the reason for this. Maybe you could try to open an issue for semver itself?

Would you mind if I close this issue?

Hi @tomschr

I just wanted to raise this issue over https://github.com/semver/ to conclude that question :)
Here's the opened request: semver/semver#540

I'm closing the issue now. Thanks for your support once again.

@P1ng-W1n Wonderful! ❤️ Thanks for opening the issue on semver. Much appreciated! 👍

Feel free to open another issue if you find one. 😉

Reopening this case, as it seems that there are at least a few use cases where this should be accepted.
Feel free to join the conversation over semver/semver#540

I'm working on fix.
BTW. in my opinion you shouldn't use commit hash in 'prerelease' part because it's used in determining precedence which is, I believe, unexpected:

>>> parse_version_info('1.0.0-e2fe98cbe') < parse_version_info('1.0.0-fc8bf7201')
True

On the other hand, 'build' part is ignored when versions are compared:

>>> parse_version_info('1.0.0+e2fe98cbe') == parse_version_info('1.0.0+fc8bf7201')
True

Hi @ppkt

The more I think about it, the more I have to agree with you. I can't think of a single hashing algorithm that could guarantee that the generated hash wouldn't start with a numeric zero AND that it wouldn't consist only of numbers (for example, 01234567 could also be a git hash).
So having any kind of hash be part of the semver version (without any prefix) would make more sense to be included as build metadata and not as part of a pre-release version.
But.. I could still imagine a few situations where "accidental numeric values" (as described in semver/semver#540) could be part of a pre-release version, such as the case with linear growing hexadecimal integers: "1.0.0-0x01"

Thanks for the quick fix.
Any estimation of when the new release (2.9.1, I guess) would be released?

@P1ng-W1n Thanks for your contribution. 👍

Any estimation of when the new release (2.9.1, I guess) would be released?

Yes, we are preparing the 2.9.1 release. You can see that in the CHANGELOG.rst file in the section Version 2.9.1 (WIP).

@scls19fr do you have any estimation? 😉
From my point of view, I think we can do it quite soon. We've collect some for 2.9.1. I would like to see the addition of the __getitem__. I think, it's stable enough to merge it if the original author would be ok.

Maybe we could even simplify the release process a bit through GitHub Actions...? If you are ok with that, I could open an issue and try something out in my fork.

I also think that a new release should occur before our 3.x.y release.
Beginning of January / mid-December would be great... Santa claus is near!
+1 about experimenting a release through GitHub Action.