[Distutils] "Specs" vs "Proposals"
wes.turner at gmail.com
Tue Sep 8 00:29:51 CEST 2015
> > 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 at 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...
> 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
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 at python.org
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the Distutils-SIG