I do think pip is pretty conservative about backwards compat other than the security related changes I've been doing.
I think we can find the middle ground that lets things work smoothly here :). I was just making sure that we wernt going to have to keep things around for really long times like python 4 ;) On Jul 14, 2013, at 3:35 AM, Nick Coghlan <ncogh...@gmail.com> wrote: > On 14 July 2013 17:13, Donald Stufft <don...@stufft.io> wrote: >> I think it would be reasonable for the pip maintainers to be asked to >> declare a public API (even if that's "None") using the naming scheme or an >> import warning and declare a backwards compatibility policy for pip itself >> so that people can know what to expect from pip. I do not however, believe >> it is reasonable to bind pip to the same policy that CPython uses nor the >> same schedule. (If you weren't suggesting that I apologize). > > The main elements of CPython's backwards compatibility policy that I consider > relevant are: > > * Use leading underscores to denote private APIs with no backwards > compatibility guarantees > * Be conservative with deprecating public APIs that aren't fundamentally > broken > * Use DeprecationWarning to give at least one (pip) release notice of an > upcoming backwards incompatible change > > We *are* sometimes quite aggressive with deprecation and removal even in the > standard library - we removed contextlib.nested from Python 3.2 as a > problematic bug magnet well before I came up with the contextlib.ExitStack > API as a less error prone replacement in Python 3.3. It's only when it comes > to core syntax and builtin behaviour that we're likely to hit issues that > simply don't have a sensible deprecation strategy, so we decide we have to > live with them indefinitely. > > That said, I think the answer to this discussion also affects the answer to > whether or not CPython maintenance releases should update to newer versions > of pip: if pip chooses to adopt a faster deprecation cycle than CPython, then > our maintenance releases shouldn't bundle updated versions. Instead, they > should follow the policy: > > * if this is a new major release, or the first maintenance release to bundle > pip, bundle the latest available version of pip > * otherwise, bundle the same version of pip as the previous release > > This would mean we'd be asking the pip team to help out by providing security > releases for the bundled version, so we can get that without breaking the > public API that's available by default. > > On the other hand, if the pip team are willing to use long deprecation cycles > then we can just bundle the updated versions and not worry about security > releases (I'd prefer that, but it only works if the pip team are willing to > put up with keeping old APIs around for a couple of years before killing them > off once the affected CPython branches go into security fix only mode). > > Cheers, > Nick. > > -- > Nick Coghlan | ncogh...@gmail.com | Brisbane, Australia
_______________________________________________ Distutils-SIG maillist - Distutils-SIG@python.org http://mail.python.org/mailman/listinfo/distutils-sig
