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.
solved Is it a good practise to remove a function instead of making it stay there with a deprecated annotation [closed]