Might be nice to support a 3rd param that's a String for the reason it's deprecated. i.e. "Replaced by X", "Unmaintained", "Obsolete", "See CASSANDRA-NNNNN", link to a dev ML thread on pony mail, etc. That way if someone comes across it in the codebase they have some context to follow up on if it's the shape of a thing they need w/out having to go full-bore w/git blame and JQL.
On Fri, Oct 6, 2023, at 4:43 AM, Miklosovic, Stefan wrote: > Hi list, > > I have a ticket to discuss (1). > > When we deprecate APIs / methods etc, what I want to suggest is that we might > start to explicitly add the version when that happened. For example, if you > deprecated something which goes to 5.0, would you be so nice to do this? > > @Deprecated(since = "5.0") > > Similarly, that annotation offers one more field - forRemoval, so using it > like this: > > @Deprecated(since = "5.0", forRemoval = true) > > means that this is eligible to be deleted in Cassandra 6.0. > > With this information, it is way more comfortable to just "grep" where we are > at when it comes to deprecations eligible to be deleted in the next version. > Currently, we basically have to go one by one and figure out if it is not old > enough to remove. I believe this would bring more transparency into what is > planned to be removed and when as well it will be clearly visible what should > be removed in the next version and it is not. > > Tangential question to this is if everything we deprecated is eligible for > removal? In other words, are there any cases when forRemoval would be false? > Could you elaborate on that and give such examples or do you all think that > everything which is deprecated will be eventually removed? > > (1) https://issues.apache.org/jira/browse/CASSANDRA-18912 > > Thanks and regards
