Deprecation schedule

[Jonathan M Davis]

On Tuesday, December 07, 2010 16:53:38 Don wrote:
> Lutger Blijdestijn wrote:
> > Jonathan M Davis wrote:
> >> On Friday 26 November 2010 11:03:03 Andrei Alexandrescu wrote:
> >>> I wonder what would be a good deprecation schedule. Consider
> >>> http://d.puremagic.com/issues/show_bug.cgi?id=5257 as an example.
> >>> 
> >>> We should now slowly deprecate std.utf.count. How should we go about
> >>> it?
> >>> 
> >>> T0: documentation marked as "scheduled for deprecation".
> >>> T1: Function is deprecated and documentation updated to mention "has
> >>> been deprecated"
> >>> T2: Function is eliminated
> >>> 
> >>> Question is, what are some good values for T1 - T0 and T2 - T1?
> >> 
> >> I think that not doing T0 and T1 at the same time only makes sense if we
> >> know that we're going to deprecate it but aren't ready to do so yet
> >> (like if we were to do another release with std.date without putting in
> >> the new std.datetime - we _know_ that we're going to deprecate
> >> std.date, but we wouldn't be ready to actually do it yet, because it's
> >> replacement wasn't yet in Phobos). So, in this case, I think that T0
> >> and T1 should be done at the same time.
> > 
> > It's helpful to know if some module is going to be deprecated in the near
> > future, even if an alternative is not ready. That is true for many
> > modules in phobos. So a for T0 should be the moment the decision is made
> > and T1 as soon as an alternative is ready - or the functionality is
> > dropped entirely.
> > 
> >> As for for how long a function should be deprecated and not yet removed,
> >> that's a bit harder. How often do people update dmd? Part of me wants to
> >> say 1 release, but I know that there are people out there who don't
> >> bother updating for a release or two. How long before having a function
> >> deprecated but still there becomes an issue (particularly if you end up
> >> with very many of them)? And given the relatively fast pace of
> >> development, if we were actually to deprecate everything that we wanted
> >> to deprecate right now, I'm not sure that it would be all that short a
> >> list (though, since it's mostly either whole modules or an entire
> >> language feature like scoped local variables rather than individual
> >> functions, the actual number of things that you'd have to list as
> >> deprecated would probably be rather short).
> >> 
> >> I'd say that T2 - T1 should be about 6 months at most at this point. If
> >> Phobos dmd and Phobos were completely stable and had been for a while,
> >> then something more like 2 years might be appropriate, but the pace of
> >> development is still too fast for that to make sense. 6 months is still
> >> a bit of an eternity for D at the moment, so that's probably enough
> >> right now. I do think, however, that it's something that should change
> >> once Phobos has become more stable.
> >> 
> >> - Jonathan M Davis
> > 
> > Although it's good to remove things, why should it be rushed? What is the
> > inconvenience of having deprecated stuff lingering?
> 
> Some features cannot be implemented until some deprecated functions have
> been completely removed.

That, and to some extent, you still have to maintain it. Just because it's 
deprecated doesn't mean that it should stop working - just that it shouldn't be 
used in any new code and that old code should be changed so that it doesn't use 
it anymore.

Also, as long as it's around people will use it. If you really want it gone, it 
needs to be gone, not just deprecated.

- Jonathan M Davis