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
