On 7 September 2015 at 09:42, Ben Finney <ben+pyt...@benfinney.id.au> wrote: > Nick Coghlan <ncogh...@gmail.com> writes: > >> On 7 September 2015 at 02:09, Marcus Smith <qwc...@gmail.com> wrote: >> > For example, down the road when there's Wheel 2.0, what's the "Current >> > Specs" for wheel? >> >> Yes, but I think that's easy enough to handle by having a default URL >> that always goes to the latest version of the spec, and moving >> previous versions to URLs that include the version number. > > <modification severity="bikeshed"> > Or consistently publish each spec version to a predictable URL with the > version number, and have the default URL *redirect* to whatever is the > current-versioned spec. > </modification> > > That way, the URL works as people expect, *and* the resulting > destination gives a URL that (when inevitably copy-and-pasted) will > retain its meaning over time.
Yes, ReadTheDocs does let us do that. However, there's actually a problem with it, and it's this: it perpetuates the myth that it is possible to publish viable packaging software without committing to ongoing maintenance of that software to track changes to distribution formats and user experience expectations. Software distribution *fundamentally* involves interacting with the outside world, and coping with evolving interoperability expectations. Users should be able to grab the latest version of a packaging tool and be confident that it supports the latest interoperability standards (modulo a rollout window of a few weeks or maybe a few months for tools designed for relatively slow moving environments). This is the problem we always hit with distutils, and the one we still regularly hit with the Linux distributions: their update and rollout cycles are too slow, so they can't keep up with user expectations. Thus, the mindset we want to cultivate amongst tool developers is "I commit to ensuring my project gains support for the latest versions of the Python packaging interoperability standards in a timely manner, as well as supporting legacy versions of those standards for backwards compatibility purposes", rather than "My project supports version 1.0 of the interoperability standards, and I might upgrade to 2.0 when that happens. If I feel like it, and I have time. Maybe". Regards, Nick. -- Nick Coghlan | ncogh...@gmail.com | Brisbane, Australia _______________________________________________ Distutils-SIG maillist - Distutils-SIG@python.org https://mail.python.org/mailman/listinfo/distutils-sig
