[Python-ideas] module version number support for semver.org

[Donald Stufft]

Oh also, this would probably be more appropriate for the distutils-sig mailing
list.

On Apr 14, 2014, at 1:41 PM, Donald Stufft <donald at stufft.io> wrote:

> 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 at 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 at 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 at 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 at 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
> 


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

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/python-ideas/attachments/20140414/47c6fe40/attachment.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 801 bytes
Desc: Message signed with OpenPGP using GPGMail
URL: <http://mail.python.org/pipermail/python-ideas/attachments/20140414/47c6fe40/attachment.sig>