rename semver* version schemes to semver-pep440-* to prevent confusion

[sschwarzer]

trafficstars

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).

[RonnyPfannschmidt]

Python version standards don't quit match general semver

[sschwarzer]

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.

[RonnyPfannschmidt]

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?

[sschwarzer]

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,

• Django uses a space before alpha, beta etc, and it doesn't use a zero as patch version, i.e. "3.2" instead of "3.2.0".
• Flask uses versions like "x.y.za2" or "x.y.zrc2", so it doesn't use a hyphen, plus or dot as separator after the patch version.
• NumPy, SciPy and pandas indeed use development versions of the form "x.y.z.dev...". (They're all organisationally related though, so it's not surprising they use the same version naming.)
• Requests doesn't seem to use any suffixes after the patch version, at least I didn't find any.
• My own project, ftputil, uses semver according to semver.org, with a hyphen between patch version and alpha/beta suffixes.

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. :-)

[RonnyPfannschmidt]

https://www.python.org/dev/peps/pep-0440/

[sschwarzer]

https://www.python.org/dev/peps/pep-0440/

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.

[sschwarzer]

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:

  • It describes which concrete standard is used.
  • Users are pointed to and hence can read PEP 440 if they want more details.
  • It makes clear that PEP 440 is used, not the replaced PEP 386. And if there's a future standard that replaces PEP 440, you can indicate its usage in a new prefix and there's no confusion what otherwise the prefix python- would mean.
  • Along the same lines, if another version naming PEP occurs in the future, you don't need to change the behavior of an already existing identifier (in the case of 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. :-)

[RonnyPfannschmidt]

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

[RonnyPfannschmidt]

there wil lbe a rename to semver-pep440 to better indicate the anesm

i wont implement additional schemes