On Oct 17, 2013, at 9:26 AM, Michael Foord <fuzzy...@gmail.com> wrote:
> > > > On 17 October 2013 16:53, Donald Stufft <don...@stufft.io> wrote: > > On Oct 17, 2013, at 11:49 AM, Michael Foord <fuzzy...@gmail.com> wrote: > >> Package upload certainly worked, and that is what is going to be broken. > > So would you be ok with deprecating and removing to equal "this metadata > silently > gets sent to /dev/null" in order to not break uploads for what would have > affected > roughly 4% of the total new releases on PyPI in 2013. > My vote on this whole thing in the general context of how to handle deprecating metadata fields * Email anyone using deprecated metadata at the time of deprecation (or now, in the case of this stuff) * Deprecation would follow a somewhat normal arc: * Initially it is just marked as deprecated in the docs (pending deprecation phase). * "One major release" (which is fuzzy in this case, but 6-12 months) later it goes to dev null on input and is removed from all output. * "One major release" later it is a fatal error. Having this whole schedule formalized will help everyone to know how we evolve the metadata spec, and because it is key-value pairs we have some wiggle room to sometimes ignore certain keys or treat them as opaque blobs (a la HTTP/MIME headers). In the case of this instance, I would say we should do the email and dev-null-ing immediately and then just pick up as normal and in 6-12 months (whatever we decide, not that it should actually be an ill-defined time period) it becomes a fatal error. --Noah
signature.asc
Description: Message signed with OpenPGP using GPGMail
_______________________________________________ Distutils-SIG maillist - Distutils-SIG@python.org https://mail.python.org/mailman/listinfo/distutils-sig
