python-semver: 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
About this issue
- Original URL
- State: closed
- Created 5 years ago
- Reactions: 1
- Comments: 15 (8 by maintainers)
Commits related to this issue
- Fix #194 and #114: Update semver regex to version from semver.org Also, fix problem with invalid Python 2.7 super call. — committed to ppkt/python-semver by ppkt 5 years ago
- Fix #194 and #114: Update semver regex to version from semver.org Also, fix problem with invalid Python 2.7 super call. — committed to ppkt/python-semver by ppkt 5 years ago
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”
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.
Hi @tomschr
I just wanted to raise this issue over https://github.com/semver/ to conclude that question 😃 Here’s the opened request: https://github.com/semver/semver/issues/540
I’m closing the issue now. Thanks for your support once again.
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.