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.tur...@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 <ncogh...@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 | ncogh...@gmail.com | Brisbane, Australia > > > > > > > > _______________________________________________ > > Distutils-SIG maillist - Distutils-SIG@python.org > > https://mail.python.org/mailman/listinfo/distutils-sig > > >
_______________________________________________ Distutils-SIG maillist - Distutils-SIG@python.org https://mail.python.org/mailman/listinfo/distutils-sig
