[Distutils] Working toward Linux wheel support

[Wes Turner]

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
document

>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**¶*
<http://docs.openstack.org/developer/pbr/semver.html#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
MAJOR.MINOR.PATCH
(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:
>>
https://read-the-docs.readthedocs.org/en/latest/user-defined-redirects.html#page-redirects
>> (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>