Acts as a supplement to @Deprecated. The idea is that we'd add this whenever we knew that a certain method/interface/class is going to be going away.
This is intended to appease the people who argue that adding deprecation before we have the alternative in place is a hard thing to deal with as they cannot fix those deprecation errors.
I'd love to see something like:
, , what do you think of possibly back-porting this to 5.2 as well and apply to things that meet this criteria?
+1 for back-porting to 5.2
, I like the idea of having @EndOfLife for this purpose.
Is asOf attribute intended to document the minor version when the @EndOfLife annotation was added? If so, that may cause confusion if it ends up getting backported to a earlier branch. I run into the same issue with @since. If I notice @since being backported, I add the micro version(s) in the earlier branches (e.g., @since 5.2, 5.1.5, 5.0.9). I wouldn't be able to do this with @EndOfLife as you have it defined, since asOf would be restricted to a single, minor version.
Would removal attribute get updated from UKNOWN to an actual version once it is known when it will be removed?
Are you intending that @EndOfLife would be temporary for those cases where an alternative will be provided? WIMI, will @EndOfLife be changed to @Deprecated if/when an alternative is available?