<div dir="ltr">Wes, this isn't about the versioning scheme for Specs or PEPS.<div>For *whatever* scheme we have,  my discussion was about how to render all the "current" versions we support in a Sphinx project.</div><div>in short, should the current versions we want to publish be distinct documents or not.</div><div><br></div><div>>  The PEP workflow is probably fine</div><div><br></div><div>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.</div><div><br></div></div><div class="gmail_extra"><br><div class="gmail_quote">On Mon, Sep 7, 2015 at 9:40 AM, Wes Turner <span dir="ltr"><<a href="mailto:wes.turner@gmail.com" target="_blank">wes.turner@gmail.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><p dir="ltr">MAJOR.MINOR.PATCH[-rev] would be helpful for these  (and other) PEPs.<br></p><span class="">
<p dir="ltr">On Sep 7, 2015 10:36 AM, "Marcus Smith" <<a href="mailto:qwcode@gmail.com" target="_blank">qwcode@gmail.com</a>> wrote:<br>
><br>
> I'm still unclear on whether you'd want A or B:<br>
><br>
> A) Different major/minor versions of the spec are different documents</p>
</span><p dir="ltr">From <a href="http://semver.org" target="_blank">http://semver.org</a> Semantic Versioning 2.0 :</p>
<p dir="ltr">```<br>
Given a version number MAJOR.MINOR.PATCH, increment the:</p>
<p dir="ltr">- MAJOR version when you make incompatible API changes,<br>
- MINOR version when you add functionality in a backwards-compatible manner, and<br>
- PATCH version when you make backwards-compatible bug fixes.</p>
<p dir="ltr">Additional labels for pre-release and build metadata are available as extensions to the MAJOR.MINOR.PATCH format.<br>
```<br></p><span class="">
<p dir="ltr">> B) Different versions of the spec are tags or branches of the same document</p>
</span><p dir="ltr">From <a href="http://docs.openstack.org/developer/pbr/semver.html" target="_blank">http://docs.openstack.org/developer/pbr/semver.html</a> :</p>
<p dir="ltr">```<br>
<b>Linux/Python Compatible Semantic Versioning 3.0.0</b></p>
<p dir="ltr">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.</p>
<p dir="ltr"><b>Changes vs </b><b>SemVer</b><b> 2.0</b><a href="http://docs.openstack.org/developer/pbr/semver.html#changes-vs-semver-2-0" target="_blank"><b>¶</b></a></p>
<p dir="ltr">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.<br>
```</p>
<p dir="ltr">Something like v1.0.01-eb4df7f[-linux64] would have greater traceability.</p><span class="">
<p dir="ltr">><br>
> If it's B, then you'd either:<br>
> 1) only build the latest version, and construct an index of links to the unrendered old versions in vcs history<br>
> 2) use a custom build/publishing worflow that pulls versions out of history so they can be built as peers in the published version</p>
</span><p dir="ltr">#. TBH I'm more concerned about determining downstream tool support from MAJOR.MINOR.PATCH<br>
(The PEP workflow is probably fine; I think there is need for  better versioning under one heading).</p>
<p dir="ltr"><span class="">><br>
><br>
><br>
><br>
><br>
> On Sun, Sep 6, 2015 at 9:26 PM, Nick Coghlan <<a href="mailto:ncoghlan@gmail.com" target="_blank">ncoghlan@gmail.com</a>> wrote:<br>
>><br>
>> On 7 September 2015 at 14:11, Marcus Smith <<a href="mailto:qwcode@gmail.com" target="_blank">qwcode@gmail.com</a>> wrote:<br>
>> ><br>
>> ><br>
>> >> > That way, the URL works as people expect, *and* the resulting<br>
>> >> > destination gives a URL that (when inevitably copy-and-pasted) will<br>
>> >> > retain its meaning over time.<br>
>> >><br>
>> >> Yes, ReadTheDocs does let us do that.<br>
>> ><br>
>> ><br>
>> > well, it lets you do it for a whole project.<br>
>><br>
>> RTD also has page redirects now:<br>
>> <a href="https://read-the-docs.readthedocs.org/en/latest/user-defined-redirects.html#page-redirects" target="_blank">https://read-the-docs.readthedocs.org/en/latest/user-defined-redirects.html#page-redirects</a><br>
>> (I thought the same thing you did, but found that when double<br>
>> checking)<br>
>><br>
>> So we *could* redirect unqualified links to qualified ones if we<br>
>> wanted to. I just don't want to :)<br>
>><br>
>> Cheers,<br>
>> Nick.<br>
>><br>
>> --<br>
>> Nick Coghlan   |   <a href="mailto:ncoghlan@gmail.com" target="_blank">ncoghlan@gmail.com</a>   |   Brisbane, Australia<br>
><br>
><br>
><br></span><span class="">
> _______________________________________________<br>
> Distutils-SIG maillist  -  <a href="mailto:Distutils-SIG@python.org" target="_blank">Distutils-SIG@python.org</a><br>
> <a href="https://mail.python.org/mailman/listinfo/distutils-sig" target="_blank">https://mail.python.org/mailman/listinfo/distutils-sig</a><br>
><br>
</span></p>
</blockquote></div><br></div>