On 5 September 2015 at 12:14, Donald Stufft <don...@stufft.io> wrote:
> On September 4, 2015 at 10:12:08 PM, Nick Coghlan (ncog...@gmail.com) wrote:>> It's only the interoperability specs where we currently follow the RFC>> model of having the same document describe both the end result *and*>> the rationale for changes from the previous version, and I mostly find>> it to be a pain.>>>> I'm not sure that I follow what you’re saying here, can you describe what your> ideal situation would look like?
1. We add a new section to packaging.python.org for "Specifications".
The specification sections of approved PEPs (compatibility tags, wheel
format, version specifiers, dist-info directories) get added there.
API specifications for index servers may also be added there.
2. Interoperability PEPs become proposals for new packaging.python.org
specifications or changes to existing specifications, rather than
specifications in their own right.
3. Each specification has a "version history" section at the bottom,
which links to the PEPs that drove each update.
This way, the PEPs can focus on transition plans, backwards
compatibility constraints, and the rationale for particular changes,
etc, but folks wanting "just the current spec, thanks" can look at the
latest version on packaging.python.org without worrying about the
It also means that the specs themselves (whether additions or updates)
can be prepared as packaging.python.org PRs.
-- Nick Coghlan | ncog...@gmail.com | Brisbane, Australia
Distutils-SIG maillist - Dist...@python.org