So i had this long argument with some guys and they kept fighting over their self made code conventions. According to which , they said if there is a method that you while coding the stuff you thought it should be deprecated.You simply remove it,change everywhere it has been used,notify others and let them change their stuff too.
What if java people simply removed the Date class instead of deprecating it and still they would not agree.
Even if i am wrong, i would expect a nice explanation to the fact. Some additional facts or links would be great.
This maybe might be something for Programmers.
If you were making a library used by others, a new version should not break existing code. Only after a major revision, say from 3.8.7 to 4.0 you might require the users to recode. Mind that other bug repairs might make a branching, a back porting to a new 3.8.8 becessary.
Mind those others might use still other libraries, that use your library too. So being backward compatible means people can upgrade without waiting that a library that uses your library is upgraded.
For a local company's internal library it might be more appealing, to remove the old API, ensuring that everyone in the firm switches to the new code.
There are still some uses for @Deprecated locally:
I had once a method with a long parameter that in the new version would be Object. I did this in a library:
/**
* Please replace the long parameter with the Object ...
*/
@Deprecated
public boolean f(long x) { ... }
public boolean f(Object x) { ... }
Here simply deleting the old version would be fatal for all library usages, apart from an ugly if (x instanceof Long) { return fOld(((Long)x).longValue()); } in the new function.
So a deprecation might give a javadoc info on what to replace the call with. Generally shown in IDEs as popup window.