Deprecation schedule

[Don]

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.

>Phobos users will still 
> be reminded by the compiler that they should update the code, which is 
> useful.