> 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.
How would you add that metadata to the version string (according to PEP 440)? Semver 3.0 (pbr)
From http://docs.openstack.org/developer/pbr/semver.html :
    Example: 1.0.0.dev8 < 1.0.0.dev9 < 1.0.0.a1.dev3 < 1.0.0.a1 < 1.0.0.b2 < 1.0.0.c1 < 1.0.0


On Mon, Sep 7, 2015 at 1:13 PM, Marcus Smith <qwcode@gmail.com> wrote:
pulling this idea out of the "Linux wheel support" thread, since it deserves it's own thread...

the idea being that we should better distinguish:
1) the current packaging "Specs" (for metadata, versions, etc...)
2) Proposals to change them

currently, we just have PEPs that serve both roles.

so the idea would be to:
1) house current specs at packaging.python.org... basically a document tree that's organized by topic, not numbers and it's free of proposal rationales, historical discussion, and transition plans etc...

https://packaging.python.org/en/latest/glossary.html#term-version-specifier -> pypa.io/en/latest/peps
* https://www.pypa.io/en/latest/peps
2) keep using the PEP process for adjusting or adding to the specs

and assuming that approach, I raised a few "publishing" questions:
1) do we publish/render all supported versions of a certain spec, or just the latest
2) if we publish them all, then how?  do we maintain separate documents for distinct versions? if not, how do we do it?

Tagged [semver 3.0 (+1)] versions can be managed *individually* with readthedocs.

One old-school way to do this would be to e.g. write a conf.py and a sphinx adapter for PEPs: https://github.com/python/peps

And copy/paste with version strings at the end of filenames


Distutils-SIG maillist  -  Distutils-SIG@python.org