Programmers Stack Exchange is a question and answer site for professional programmers interested in conceptual questions about software development. Join them; it only takes a minute:

Sign up
Here's how it works:
  1. Anybody can ask a question
  2. Anybody can answer
  3. The best answers are voted up and rise to the top

If you deprecate something, are you guaranteeing you will get rid of it in the next major release? Is it reasonable to take two or three releases before you get rid of it completely?

Update: Thanks for the answers. Java is a good standard for how to do this - any others? Any examples from Microsoft's APIs?

Update2: It seems like in "Microsoft-ese," deprecation means "it's going away in the next release." Which was part of my confusion; others don't endow the word with this meaning.

share|improve this question

migrated from Jun 10 '11 at 21:17

This question came from our site for professional and enthusiast programmers.

up vote 11 down vote accepted

As such, deprecation is not a commitment to remove something.

It's more of a statement "this should not be used for some reason". Deprecated API can be removed eventually, but if (and when) this will be done depends heavily on the project.

A project should define and publish a rule of when deprecated API is removed and stick with it.

The Java SE API, for example has yet to remove any API that has been deprecated, some of which exists since Java 1.0 (please correct me if I missed something).

share|improve this answer
They're not going to remove any of it. That would break the "write once, run anywhere" feature. :-) – Chris Jester-Young Jun 9 '11 at 12:35
@Chris: They won't remove it from the JRE, but they could make the compiler start making uses of that API errors. (Don't see them doing that but it would be possible) – Billy ONeal Jun 11 '11 at 0:25
Thread.stop() and Thread.suspend() are still alive and kicking though they were deprecated since Java 1.1, if I remember correctly. They are not used anymore since they are inherently unsafe, but they are still present in the API. – Malcolm Nov 9 '11 at 19:40

Lots of things get deprecated in the C++ Standard. This means they may be removed from future standards, but not necessarily the next one (or the one after that). And some things get undeprecated! For example, the use of static at namespace scope was deprecated in the first C++ standard and has now been undeprecated in the coming standard. So go figure.

But bottom line - no deprecated features will ever go away. C++ compilers will go on supporting them till doomsday (though probably giving warnings when they are used) because of the vast sea of code out there that uses them.

share|improve this answer

No. For an example, see the list of Java 6's deprecated APIs. Some of those have been deprecated since 1.3, yet the code still compiles and works (which is kind of the point). Deprecation is a warning - "don't rely on this, it may break or go away eventually".

Some vendors deprecate their APIs by a certain date (e.g. Google Translate API will die this year), some will just mark the API "deprecated", yet keep it indefinitely (e.g. aforementioned Java).

share|improve this answer
Some have been deprecated since 1.1, e.g., the non-Unicode-compliant string constructor. – Chris Jester-Young Jun 9 '11 at 12:39
@Chris Jester-Young: Well, 1.1 is somewhat old-ish; supporting IE4 doesn't make sense today, does it? (and in that case you mention, I definitely see the potential for confusion - see MSSQL's VARCHAR and NVARCHAR) – Piskvor Jun 9 '11 at 13:00
Right, and yet it still remains the Java team's policy to not break any code that's still designed for (and compiled in) 1.0. – Chris Jester-Young Jun 9 '11 at 13:13

No, there is no specific timeframe. For example, in the Java class library, obsolete functionality is marked deprecated, but they never, ever get removed.

share|improve this answer

Your Answer


By posting your answer, you agree to the privacy policy and terms of service.

Not the answer you're looking for? Browse other questions tagged or ask your own question.