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