> 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
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...)vs2) Proposals to change themcurrently, 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...
2) keep using the PEP process for adjusting or adding to the specsand assuming that approach, I raised a few "publishing" questions:1) do we publish/render all supported versions of a certain spec, or just the latest2) if we publish them all, then how? do we maintain separate documents for distinct versions? if not, how do we do it?
Distutils-SIG maillist - Distutils-SIG@python.org