On 5 September 2015 at 12:14, Donald Stufft <don...@stufft.io> wrote: > On September 4, 2015 at 10:12:08 PM, Nick Coghlan (ncogh...@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 history. It also means that the specs themselves (whether additions or updates) can be prepared as packaging.python.org PRs. Cheers, Nick. -- Nick Coghlan | ncogh...@gmail.com | Brisbane, Australia _______________________________________________ Distutils-SIG maillist - Distutils-SIG@python.org https://mail.python.org/mailman/listinfo/distutils-sig
