[Distutils] Working toward Linux wheel support

[Marcus Smith]

Wes, this isn't about the versioning scheme for Specs or PEPS.
For *whatever* scheme we have,  my discussion was about how to render all
the "current" versions we support in a Sphinx project.
in short, should the current versions we want to publish be distinct
documents or not.

>  The PEP workflow is probably fine

well, if you look up in the thread, a few of us are saying it's not.  It
doesn't distinguish Current Specs vs Proposals very well.


On Mon, Sep 7, 2015 at 9:40 AM, Wes Turner <wes.turner at gmail.com> wrote:

> 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/b39cfac6/attachment.html>