Deprecation schedule

[Jason House]

T0 - As soon as there are concrete plans for a replacement. I'd also mark sub-par modules as"looking for someone to replace this". Truth in advertising is always appreciated.
T1 - As soon as replacement code is available or maybe a month after it's available. Regardless, I'd update the scheduled for documentation bit with instructions on using the new API as soon as it's available.
T2 - This should be quite long. There's no reason to leave active projects with a non-compiling code base just because an API in a low priority area has changed. I would say something like 6-12 months. What do other languages do?

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?
> 
> 
> Andrei