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
