Open sschwarzer opened 2 years ago
Python version standards don't quit match general semver
Sorry, I should have been more explicit. I meant that version schema names that have "semver" in the name, like "python-simplified-semver" and "release-branch-semver", should conform to semver. At least that's what I'd expect and probably many others.
As currently nobody has defined a correct mapping of semver to the python standards, that's not sanely possible
Any suggestions for a solution there?
After having checked a few Python projects, I'm skeptical that there even is a "Python standard" or "Python standards."
From the projects I checked,
My impression is that version numbers/names among Python projects vary quite a bit.
My suggestion therefore is to change the version scheme name "python-simplified-semver" to "simplified-semver" and use a hyphen instead of the dot after the patch version (to conform to semver.org). Similarly, change the version scheme "release-branch-semver" to use a hyphen instead of a dot. If you still want a version scheme that uses a dot instead of a hyphen, give it a name that doesn't include "semver", to avoid confusion.
In my opinion, we should try to have fewer rather than more "standards" (if at all reasonable). This xkcd comic comes to mind. :-)
That's very interesting, thank you! That's sufficiently "standardy" for me. ;-)
I plan to send an updated suggestion for the version schemes today or tomorrow.
So here's an updated suggestion for the version schemes:
Generally, I think it would be good to prefix the names with the version schemes to show the used standard behind them.
pep440-*
, for example pep440-post
or pep440-dev
, would show that the version scheme is based on PEP 440. This has several (related) advantages:
python-
would mean.python-*
).semver-*
for version schemes that conform to Semver. Similarly to pep440-*
, it may make sense to use semver2-*
to be more specific.
If you use Semver with a post
(or dev
suffix), you could use concrete versions like 1.2.3-post4
, so the suffix (apart from the hyphen instead of a dot) would be consistent with the PEP 440 scheme (1.2.3.post4
). An alternative for Semver might be 1.2.3-post.4
since Semver defines the sort order for versions in this case so that numeric-only dot-separated parts after the hyphen are sorted numerically, so 1.2.3-post.2
would be sorted before 1.2.3-post.10
(see point 11.4.1 of the Semver spec). But I have no idea if users will want to sort these versions. Maybe that's too subtle, I don't know. It just occurred to me, so I wanted to mention it. :-)
hmm,
i shall consider renaming the existing methods (and leaving aliases in place)
i will not implement anything matching the semver standard in detail, as i do not use it personally, and the finer details seem absolutely and harrowing error prone
i will take a while to get back at figuring a good name for the semver-ish ness
there wil lbe a rename to semver-pep440 to better indicate the anesm
i wont implement additional schemes
The README of setuptools_scm mentions appending
.devN
for Semver version numbers, but according to Semver the minor version number may only be followed by a-
or a+
.You can also check the constructed version numbers with the regular expressions on the semver.org site (further down in the FAQ).