Re: [Distutils] Working toward Linux wheel support

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....@gmail.com> wrote:

> MAJOR.MINOR.PATCH[-rev] would be helpful for these  (and other) PEPs.>> On Sep 7, 2015 10:36 AM, "Marcus Smith" <qwc...@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 <ncog...@gmail.com> wrote:> >>> >> On 7 September 2015 at 14:11, Marcus Smith <qwc...@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   |   ncog...@gmail.com   |   Brisbane, Australia> >> >> >> > _______________________________________________> > Distutils-SIG maillist  -  Dist...@python.org> > https://mail.python.org/mailman/listinfo/distutils-sig> >>