[Distutils] Working toward Linux wheel support

Wes Turner wes.turner at gmail.com
Mon Sep 7 18:40:07 CEST 2015

MAJOR.MINOR.PATCH[-rev] would be helpful for these  (and other) PEPs.

On Sep 7, 2015 10:36 AM, "Marcus Smith" <qwcode at gmail.com> wrote:
> I'm still unclear on whether you'd want A or B:
> A) Different major/minor versions of the spec are different documents

>From http://semver.org Semantic Versioning 2.0 :

Given a version number MAJOR.MINOR.PATCH, increment the:

- MAJOR version when you make incompatible API changes,
- MINOR version when you add functionality in a backwards-compatible
manner, and
- PATCH version when you make backwards-compatible bug fixes.

Additional labels for pre-release and build metadata are available as
extensions to the MAJOR.MINOR.PATCH format.

> B) Different versions of the spec are tags or branches of the same

>From http://docs.openstack.org/developer/pbr/semver.html :

*Linux/Python Compatible Semantic Versioning 3.0.0*

This is a fork of Semantic Versioning 2.0. The specific changes have to do
with the format of pre-release and build labels, specifically to make them
not confusing when co-existing with Linux distribution packaging and Python
packaging. Inspiration for the format of the pre-release and build labels
came from Python’s PEP440.

*Changes vs **SemVer** 2.0**¶*

dev versions are defined. These are extremely useful when dealing with CI
and CD systems when ‘every commit is a release’ is not feasible.All
versions have been made PEP-440 compatible, because of our deep roots in
Python. Pre-release versions are now separated by . not -, and use a/b/c
rather than alpha/beta etc.

Something like v1.0.01-eb4df7f[-linux64] would have greater traceability.

> If it's B, then you'd either:
> 1) only build the latest version, and construct an index of links to the
unrendered old versions in vcs history
> 2) use a custom build/publishing worflow that pulls versions out of
history so they can be built as peers in the published version

#. TBH I'm more concerned about determining downstream tool support from
(The PEP workflow is probably fine; I think there is need for  better
versioning under one heading).

> On Sun, Sep 6, 2015 at 9:26 PM, Nick Coghlan <ncoghlan at gmail.com> wrote:
>> On 7 September 2015 at 14:11, Marcus Smith <qwcode at gmail.com> wrote:
>> >
>> >
>> >> > That way, the URL works as people expect, *and* the resulting
>> >> > destination gives a URL that (when inevitably copy-and-pasted) will
>> >> > retain its meaning over time.
>> >>
>> >> Yes, ReadTheDocs does let us do that.
>> >
>> >
>> > well, it lets you do it for a whole project.
>> RTD also has page redirects now:
>> (I thought the same thing you did, but found that when double
>> checking)
>> So we *could* redirect unqualified links to qualified ones if we
>> wanted to. I just don't want to :)
>> Cheers,
>> Nick.
>> --
>> Nick Coghlan   |   ncoghlan at gmail.com   |   Brisbane, Australia
> _______________________________________________
> Distutils-SIG maillist  -  Distutils-SIG at python.org
> https://mail.python.org/mailman/listinfo/distutils-sig
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/distutils-sig/attachments/20150907/642ecd21/attachment.html>

More information about the Distutils-SIG mailing list