So what i’d like to have happen (this part is here) is that PEP440 describes
the syntax of versions in a way that enables as many possible versions for
what is already on PyPI and that provides a definitive way for tools to parse,
and interpret the version strings.

Then what i’d like to have happen (this part hasn’t happened yet) is another
PEP or document of some sort recommending the “sane” subset of PEP440
and pushes people towards semantic like versioning within the constraints
of PEP440.

As far as just straight out adopting semver, it’s unlikely to happen because
while the semantics match what a lot of people do, the syntax doesn’t.

On Apr 14, 2014, at 1:22 PM, Guido van Rossum <guido@python.org> wrote:

What does "official support" mean? It might be more productive if you had some code that you wanted to adopt, with an explanation of why it should go into the stdlib.


On Mon, Apr 14, 2014 at 11:51 AM, Jörn Hees <dev@joernhees.de> wrote:
Hi,

what do you think about officially supporting Semantic Versioning?
( http://semver.org )

Semantic Versioning has gained a lot of attention in other programming
languages. Even though not officially supported, many python libraries use it
as well (just search the pypi listing for things like "-alpha" "-beta" "-dev"
"-pre" to get a rough idea). There even is a class handling Semantic Versioning
in pip already: pip.util.version.SemanticVersion .

I'd speak in favor of officially adding support for semantic versioning to the
python module versioning specs as a follow up to PEP 440
( http://legacy.python.org/dev/peps/pep-0440/ ).

I want to avoid the fruitless discussion about personal versioning scheme
preference.
My main point is: both schemes are widely used (even in the python world).
As far as i can see both schemes can just co-exist in the python world giving
us the benefits of both without hurting us.



Short re-cap of both versioning schemes
=======================================

The current version format specified in PEP 440 [2] follows this pseudo format:
[N:]N(.N)*[{a|b|c|rc}N][.postN][.devN]

So python module version numbers look like (taken from [2]):
1.0.dev456
1.0a1
1.0a2.dev456
1.0a12.dev456
1.0a12
1.0b1.dev456
1.0b2
1.0b2.post345.dev456
1.0b2.post345
1.0c1.dev456
1.0c1
1.0
1.0.post456.dev34
1.0.post456
1.1.dev1


Semantic Versioning follows this pseudo format:
N.N.N(-((N)|([0-9A-Za-z-]+))(.((N)|([0-9A-Za-z-])+))*)?

Some examples in order (taken from http://semver.org ):
1.0.0-alpha
1.0.0-alpha.1
1.0.0-alpha.beta
1.0.0-beta
1.0.0-beta.2
1.0.0-beta.11
1.0.0-rc.1
1.0.0



Key differences
===============

Semantic Versioning supports
- free-text pre-releases without version number such as '-alpha', '-pre' and
the very widely used '-dev' (after a release the next commit increases the
version number and appends the '-dev', which is only removed for the release).
- always has MAJOR.MINOR.PATCH, (so 3 relevant) numbers as version number and
offers guidelines which to change when.

Semantic Versioning does not support
- post-releases (a post release would be an increase of the PATCH number).
- special handling for '-dev', '-alpha', '-beta', '-gamma' or 'rc'.



Ideas to solve (cross scheme) comparisons
=========================================

A version comparator could first try parsing both versions to be compared
according to the current scheme and if that fails try parsing them both as
SemanticVersions.
Switching from one version naming scheme to another should be discouraged at
least within the leading N parts at the change boundary staying the same. That
way comparisons between the naming schemes could be settled by comparing the
leading numerical parts of the version.



Cheers,
Jörn

_______________________________________________
Python-ideas mailing list
Python-ideas@python.org
https://mail.python.org/mailman/listinfo/python-ideas
Code of Conduct: http://python.org/psf/codeofconduct/



--
--Guido van Rossum (python.org/~guido)
_______________________________________________
Python-ideas mailing list
Python-ideas@python.org
https://mail.python.org/mailman/listinfo/python-ideas
Code of Conduct: http://python.org/psf/codeofconduct/


-----------------
Donald Stufft
PGP: 0x6E3CBCE93372DCFA // 7C6B 7C5D 5E2B 6356 A926 F04F 6E3C BCE9 3372 DCFA