Create an @EndOfLife corollary to @Incubating

Description

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:

Environment

None

Activity

Show:
Steve Ebersole
June 23, 2017, 2:56 PM

, , what do you think of possibly back-porting this to 5.2 as well and apply to things that meet this criteria?

Andrea Boriero
June 23, 2017, 3:07 PM

+1 for back-porting to 5.2

Gail Badner
July 11, 2017, 10:58 PM

, 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?

Assignee

Unassigned

Reporter

Steve Ebersole

Fix versions

Labels

None

backPortable

None

Suitable for new contributors

None

Requires Release Note

None

Pull Request

None

backportDecision

None

Priority

Major
Configure