www.digitalmars.com         C & C++   DMDScript  

digitalmars.D - Deprecation schedule

reply Andrei Alexandrescu <SeeWebsiteForEmail erdani.org> writes:
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
Nov 26 2010
next sibling parent reply bearophile <bearophileHUGS lycos.com> writes:
Andrei:

 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?

T0 = T1 = 0 seconds T2 = 2 months (2 releases) One year from now, in a similar situation: T0 = 0 seconds, documentation marked as "scheduled for deprecation in next release". T1 = 1 release (1 month) T2 = 3-6 releases (3 - 6 months) Bye, bearophile
Nov 26 2010
parent Lutger Blijdestijn <lutger.blijdestijn gmail.com> writes:
bearophile wrote:

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

T0 = T1 = 0 seconds T2 = 2 months (2 releases) One year from now, in a similar situation: T0 = 0 seconds, documentation marked as "scheduled for deprecation in next release". T1 = 1 release (1 month) T2 = 3-6 releases (3 - 6 months) Bye, bearophile

That is very harsh for T2, it means that at this point anything you write might not compile anymore with the newest phobos in just 5 weeks time. Even 3 months is short, especially for a more stable point in time. I'd rather have T1 earlier and last longer, that way you can still compile the code.
Dec 07 2010
prev sibling next sibling parent reply Jonathan M Davis <jmdavisProg gmx.com> writes:
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. 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
Nov 26 2010
parent reply Lutger Blijdestijn <lutger.blijdestijn gmail.com> writes:
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.
Dec 07 2010
next sibling parent reply Don <nospam nospam.com> writes:
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?

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. 

Dec 07 2010
parent Bruno Medeiros <brunodomedeiros+spam com.gmail> writes:
On 08/12/2010 00:53, Don wrote:
 Lutger Blijdestijn wrote:
 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.

I'm surprised that's the case, what exactly are those features? I think that likely there should not be a constant rule for (T2 - T1). It depends on how much value is gained by removing the deprecated feature. If the new API can coexist with the deprecated one without drawbacks, and there is not much maintenance work done on the deprecated implementation, there is little gain in removing it, so I agree with Lutger that (T2 - T1) should be long. But otherwise it should be shorter, yeah. -- Bruno Medeiros - Software Engineer
Dec 07 2010
prev sibling parent Jonathan M Davis <jmdavisProg gmx.com> writes:
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
Dec 07 2010
prev sibling next sibling parent reply Jason House <jason.james.house gmail.com> writes:
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

Nov 26 2010
next sibling parent reply Jonathan M Davis <jmdavisProg gmx.com> writes:
On Friday 26 November 2010 15:19:37 Jason House wrote:
 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?

Java marks stuff as deprecated and then _never_ removes it. It makes the deprecation a bit of a joke really. Many people continue to use the deprecated stuff anyway. A prime example would be that they deprecated Date's most useful constructors in an effort to make you use the Calendar stuff. People keep on using those constructors anyway, because they don't care about the Calendar stuff, and it's a lot more of a pain to use. As far as I know, Sun has _never_ actually removed a deprecated function from Java's standard library (and if they haven't before, now they never will since they were eaten by Oracle - who knows what Oracle will do). Certainly, whatever we do, we don't want to follow Java's route. Hopefully there are other languages out there which handle deprecation better. Since I've mostly been a C++ and Java guy though, I'm not at all familiar with how other languages deal with it. Python would probably be a good place to look though, since they generally seem to be pretty organized. - Jonathan M Davis
Nov 26 2010
next sibling parent Stewart Gordon <smjg_1998 yahoo.com> writes:
On 26/11/2010 23:44, Jonathan M Davis wrote:
<snip>
 Java marks stuff as deprecated and then _never_ removes it. It makes the
 deprecation a bit of a joke really. Many people continue to use the deprecated
 stuff anyway. A prime example would be that they deprecated Date's most useful
 constructors in an effort to make you use the Calendar stuff. People keep on
using
 those constructors anyway, because they don't care about the Calendar stuff,
and
 it's a lot more of a pain to use.

Hooray for Phobos's "simple operations should be simple" philosophy! Another example of a pain in Java is GridBagLayout. If only Java had that philosophy, I suppose GridBagLayout would never have been invented. (Sun did eventually publish something better - TableLayout - but for some reason it hasn't become a standard API feature.)
 As far as I know, Sun has _never_ actually
 removed a deprecated function from Java's standard library (and if they haven't
 before, now they never will since they were eaten by Oracle - who knows what
 Oracle will do).

I wonder when/if they're going to get rid of Thread.destroy, which was in the API for many years but never implemented.
 Certainly, whatever we do, we don't want to follow Java's route. Hopefully
there
 are other languages out there which handle deprecation better.

But does Java ever deprecate language features, or only API features? In the latter case, it's a matter of other libraries/APIs, not other languages. Stewart.
Nov 26 2010
prev sibling next sibling parent reply Jacob Carlborg <doob me.com> writes:
On 2010-11-27 00:44, Jonathan M Davis wrote:
 On Friday 26 November 2010 15:19:37 Jason House wrote:
 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?

Java marks stuff as deprecated and then _never_ removes it. It makes the deprecation a bit of a joke really. Many people continue to use the deprecated stuff anyway. A prime example would be that they deprecated Date's most useful constructors in an effort to make you use the Calendar stuff. People keep on using those constructors anyway, because they don't care about the Calendar stuff, and it's a lot more of a pain to use. As far as I know, Sun has _never_ actually removed a deprecated function from Java's standard library (and if they haven't before, now they never will since they were eaten by Oracle - who knows what Oracle will do). Certainly, whatever we do, we don't want to follow Java's route. Hopefully there are other languages out there which handle deprecation better. Since I've mostly been a C++ and Java guy though, I'm not at all familiar with how other languages deal with it. Python would probably be a good place to look though, since they generally seem to be pretty organized. - Jonathan M Davis

It seems like that developers using Java are very afraid of removing anything. If I recall correctly the SWT library contains several classes/interfaces with a 2 appended to the end of the name just because they don't want to remove the old class/interface. -- /Jacob Carlborg
Nov 27 2010
parent Stewart Gordon <smjg_1998 yahoo.com> writes:
On 27/11/2010 17:04, Jacob Carlborg wrote:
<snip>
 It seems like that developers using Java are very afraid of removing
 anything. If I recall correctly the SWT library contains several
 classes/interfaces with a 2 appended to the end of the name just because
 they don't want to remove the old class/interface.

Adding methods to an existing interface creates immediate backward incompatibility, no wait for the interface to be removed. It's like changing the parameter list of a function. Stewart.
Nov 27 2010
prev sibling parent reply Stewart Gordon <smjg_1998 yahoo.com> writes:
On 26/11/2010 23:44, Jonathan M Davis wrote:
 On Friday 26 November 2010 15:19:37 Jason House wrote:
 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?

Java marks stuff as deprecated and then _never_ removes it.

Thinking about it now, I can see why. Java .class files don't contain implementations of the Java APIs - they pull them up from the JRE on demand. So if stuff were removed, old programs would stop working, not just stop compiling. Though I suppose they could do something like declare Java 1 obsolete, and then another few years down the line start to remove stuff. Maybe with a warning for anyone who tries to use a Java 1 app that it may not function correctly. (Do .class files store such version info?) .exe files, OTOH, have the library code they rely on embedded in them. So removing something from a library won't break these old binaries. Stewart.
Nov 27 2010
parent Bruno Medeiros <brunodomedeiros+spam com.gmail> writes:
On 27/11/2010 17:04, Stewart Gordon wrote:
 On 26/11/2010 23:44, Jonathan M Davis wrote:
 On Friday 26 November 2010 15:19:37 Jason House wrote:
 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?

Java marks stuff as deprecated and then _never_ removes it.

Thinking about it now, I can see why. Java .class files don't contain implementations of the Java APIs - they pull them up from the JRE on demand. So if stuff were removed, old programs would stop working, not just stop compiling.

Yup, there are no equivalent of "executables" in Java compilation artifacts, only the .class files which are the equivalent of "shared libraries". Thus binary compatibility is a constant issue.
 Though I suppose they could do something like declare Java 1 obsolete,
 and then another few years down the line start to remove stuff.
 Maybe
 with a warning for anyone who tries to use a Java 1 app that it may not
 function correctly.(Do .class files store such version info?)

.class files do have version info, but that relates to bytecode compatibility only, it specifies to the minimum *VM* interpreter required (1.4, 1.5, 1.6, etc.). But it says nothing about the minimum JRE (standard library) required, which can be higher (but not lower). The problem with removing stuff in the JRE in a breaking manner, is that in enterprise software you often have a system with *lots* of middleware, libraries, other third-party software, etc., in the same Java program. If just one of them requires that deprecated API, removing that API could make the whole system not run, in newer VM's at least. And often such software is closed-source, so you can't just modify it to run on newer JREs. So they have to be very mindful of that. The other thing (especially with APIs) is that sometimes there is no significant advantage in actually removing deprecated stuff: just having the people switch to an alternate component/library is good enough (like the Calendar example). Removing is only more significant when the two APIs (newer and older) cannot coexist at the same time (or cannot do so easily). -- Bruno Medeiros - Software Engineer
Dec 07 2010
prev sibling parent reply Russel Winder <russel russel.org.uk> writes:
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

On Fri, 2010-11-26 at 15:44 -0800, Jonathan M Davis wrote:

 Java marks stuff as deprecated and then _never_ removes it. It makes the=

 deprecation a bit of a joke really. Many people continue to use the depre=

Not entirely true. There was some stuff that Sun actually removed between 1.3 and 1.4 I think but there was a huge outcry and so it was all put back in (undeprecated!) for 1.5. I can't remember the exact details but there were two issues: 1. The items in question should not have been deprecated in the first place. 2. The whole incident, and Sun's obsessive commitment to backwards compatibility, meant that nothing ever got removed again. On the whole though, it is true Sun should have removed things that have been deprecated.=20
 stuff anyway. A prime example would be that they deprecated Date's most u=

 constructors in an effort to make you use the Calendar stuff. People keep=

 those constructors anyway, because they don't care about the Calendar stu=

 it's a lot more of a pain to use. As far as I know, Sun has _never_ actua=

 removed a deprecated function from Java's standard library (and if they h=

 before, now they never will since they were eaten by Oracle - who knows w=

 Oracle will do).

Actually the whole Calendar thing should not only be deprecated as a whole, it should be ignored as of now. Use only JodaTime!
 Certainly, whatever we do, we don't want to follow Java's route. Hopefull=

 are other languages out there which handle deprecation better. Since I've=

 been a C++ and Java guy though, I'm not at all familiar with how other la=

 deal with it. Python would probably be a good place to look though, since=

 generally seem to be pretty organized.

I guess the prime example here is Fortran -- they end up not being allowed to deprecate anything, let along remove it from the language. It never ceases to amaze me that the committee manages to evolve the language and yet still be able to compile all the 1960s legacy code that everyone colludes in finding no-one willing to rewrite. This is not a negative comment on the Fortran language evolution people, exactly the opposite, but it is an indictment of a society that chooses to insist that old code that works not be rewritten even though hardware has moved on significantly making the code significantly past its use-by date.=20 --=20 Russel. =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D Dr Russel Winder t: +44 20 7585 2200 voip: sip:russel.winder ekiga.n= et 41 Buckmaster Road m: +44 7770 465 077 xmpp: russel russel.org.uk London SW11 1EN, UK w: www.russel.org.uk skype: russel_winder
Nov 27 2010
parent Walter Bright <newshound2 digitalmars.com> writes:
Russel Winder wrote:
 I guess the prime example here is Fortran -- they end up not being
 allowed to deprecate anything, let along remove it from the language.
 It never ceases to amaze me that the committee manages to evolve the
 language and yet still be able to compile all the 1960s legacy code that
 everyone colludes in finding no-one willing to rewrite.  This is not a
 negative comment on the Fortran language evolution people, exactly the
 opposite, but it is an indictment of a society that chooses to insist
 that old code that works not be rewritten even though hardware has moved
 on significantly making the code significantly past its use-by date. 

On the other hand, even small incompatibilities moving from D1 to D2 create problems for people. Fortran's longevity may be in part attributable to its perfect legacy compatibility. After all, if you're going to force a rewrite of the old code, one might as well move to a more modern language.
Nov 27 2010
prev sibling next sibling parent Daniel Gibson <metalcaedes gmail.com> writes:
Andrei Alexandrescu schrieb:
 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

T0: As soon as it's decided that the function will be replaced T1: Once the replacement is available and usable (tested, considered mostly stable) T2: If the function was available in phobos1: never/for D3. That would make porting of D1/Phobos1 code to D2 a lot easier - one could replace the use of deprecated functions bit by bit instead of having to overhaul the whole project before being able to compile it for D2 - or, at least you'd only have to fix stuff concerning changes in the language (const, TLS, etcpp) at first. If it wasn't available in phobos1: Within 2 or 3 DMD releases? Cheers, - Daniel
Nov 26 2010
prev sibling parent Jonathan M Davis <jmdavisProg gmx.com> writes:
On Friday 26 November 2010 18:38:20 Stewart Gordon wrote:
 But does Java ever deprecate language features, or only API features?
 In the latter case, it's a matter of other libraries/APIs, not other
 languages.

That's true. I'm not sure that they've ever deprecated a language feature. I don't _think_ so, but I'm not 100% sure. I'd be surprised. It's more of a library thing really. So, maybe looking at what the deal is with something like Apache Commons would be a good place to look. - Jonathan M Davis
Nov 26 2010