Deprecation schedule

[Lutger Blijdestijn]

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? Phobos users will still 
be reminded by the compiler that they should update the code, which is 
useful.