[Python-Dev] When to remove deprecated stuff

[R. David Murray]

On Thu, 22 Aug 2013 20:00:14 +0200, Ezio Melotti <ezio.melotti at gmail.com> wrote:
> On Thu, Aug 22, 2013 at 4:43 PM, R. David Murray <rdmurray at bitdance.com> wrote:
> > On Thu, 22 Aug 2013 16:45:29 +0300, Michael Foord <fuzzyman at voidspace.org.uk> wrote:
> >>
> >> On 22 Aug 2013, at 14:00, Petri Lehtinen <petri at digip.org> wrote:
> >> >
> >> > Django's deprecation policy works like this: They deprecate something
> >> > in version A.B. It still works normally in A.B+1, generates a
> >> > (silenced) DeprecationWarning in A.B+2, and is finally removed in
> >> > A.B+3. So if I haven't read through the full release notes of each
> >> > release nor enabled DeprecationWarnings, I end up having something
> >> > broken each time I upgrade Django.
> >> >
> >>
> >> So you're still using features deprecated three releases ago, you haven't checked for DeprecationWarnings and it's Django making your life difficult?
> >>
> >> Why not check for the deprecation warnings?
> >
> > Doing so makes very little difference.
> >
> > This is my opinion (others obviously differ):
> >
> > Putting in one big chunk of effort at a major release boundary is easier
> > to schedule than putting in a chunk of effort on *every* feature
> > release.
> 
> IMHO there is a third (and better option) that you are missing.
> 
> Assume I'm using A.B, and see some DeprecationWarnings.  Now I have at
> least 1.5 years to fix them before A.B+1 is released, and once that
> happens there shouldn't be any warnings left so I can upgrade
> successfully.  Once I do, more warnings will pop up, but then again I
> will have 1.5+ years to fix them.
> 
> It seems to me that the problem only arises when the developers ignore
> (or possibly are unaware of) the warnings until it's time to upgrade.

I think you missed my point.  It is the *change itself* that causes
action to be needed.  If a project has a policy of dealing with deprecated
features when the warnings happen, then they need to do that work before
the version where the feature is removed is released.  If they have
a policy of ignoring deprecation warnings, then they have to do that
work before their users can upgrade to the version where the feature
is removed.  So the pain exists in equal measure either way, with the
same periodicity, only the timing of when the work is done is affected
by whether or not you pay attention to deprecation warnings.  And yes,
you presumably have a more relaxed fix schedule and happier users if
you pay attention to deprecation warnings, so you should do that (IMO).

I'm asking if the bigger removals should be only on major version
boundaries, thus allowing *more* time for that relaxed fix mode for the
stuff that takes more work to fix.

It does occur to me that this would mean we'd bikeshed about whether any
given change was major or not...but we'd do that anyway, because we'd
argue about h^h^h^h^h^h^h^h^h discuss how many releases to wait before
actually removing it, depending on how disruptive it was likely to be.

--David