+1 on reason string, especially some way to indicate what replaces a method if it’s being moved into some other class/new method with more parameters/etc. I’ve found lots of cases (in code bases in general, not C* in particular) where something is marked as Deprecated but there’s no mention of a replacement even when there is one.
As someone who has spent a bunch of time using parts of Cassandra as a library, this would be hugely beneficial, but it would also clearly be useful for maintainers of the core codebase. Doug > On Oct 6, 2023, at 7:49 AM, Josh McKenzie <jmcken...@apache.org> wrote: > > 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
