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
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...) vs 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 * https://github.com/pypa/pypa.io/blob/master/source/peps.rst
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
--Marcus
_______________________________________________ Distutils-SIG maillist - Distutils-SIG@python.org https://mail.python.org/mailman/listinfo/distutils-sig