Semver validation error when prerelease version contains a floating number

Could someone please verify if that’s intended? I can’t see any restriction about this in the semver documentation.

PoC:

$ python3 --version
Python 3.6.8
$ pip3 list --format=legacy |grep semver
semver (2.9.0)
$ python3
Python 3.6.8 (default, Oct  7 2019, 12:59:55) 
[GCC 8.3.0] on linux
Type "help", "copyright", "credits" or "license" for more information.
>>> import semver
>>> semver.parse('0.1.0-20191919191919.1fe6b123')
{'major': 0, 'minor': 1, 'patch': 0, 'prerelease': '20191919191919.1fe6b123', 'build': None}
>>> semver.parse('0.1.0-20191919191919.0fe6b123')
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
  File "/home/ezlukga/.local/lib/python3.6/site-packages/semver.py", line 72, in parse
    raise ValueError('%s is not valid SemVer string' % version)
ValueError: 0.1.0-20191919191919.0fe6b123 is not valid SemVer string
>>> semver.parse('0.1.0-20191919191919.0f')
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
  File "/home/ezlukga/.local/lib/python3.6/site-packages/semver.py", line 72, in parse
    raise ValueError('%s is not valid SemVer string' % version)
ValueError: 0.1.0-20191919191919.0f is not valid SemVer string
>>> semver.parse('0.1.0-0f')
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
  File "/home/ezlukga/.local/lib/python3.6/site-packages/semver.py", line 72, in parse
    raise ValueError('%s is not valid SemVer string' % version)
ValueError: 0.1.0-0f is not valid SemVer string

[P1ng-W1n]

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 https://github.com/semver/semver/issues/540) could be part of a pre-release version, such as the case with linear growing hexadecimal integers: “1.0.0-0x01”

[scls19fr]

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.