I can definitely see a logic in not removing. When I saw deprecated annotations for the first time after I mapped where we deprecated it, my initial desire was to invent some logic to remove it all after some period of time but that is not a good idea after all.
We had a thread about this here (1) and the consensus we seemed to reach was that if it is cheap to keep it around indefinitely, we just should keep it. There is no real value in removing it when it just sits there and calls non-deprecated code and us removing it would just introduce problems for users who integrate with that. There is also a field called "forRemoval" in @Deprecated annotation which might signal that something is _really_ meant to be removed, but Mick here suggested (2) that would require broader consensus on ML, to mark the code like that, which is perfectly reasonable. The most common example is deprecation of some JMX methods. We can not possibly know who is using it out there and removing it just for the sake of removal is really questionable. Based on the mapping here (3) the only things we are going to really remove are these which are not public-facing. If one spent enough time looking into these deprecations, people would realize that it is really "case by case". We also can not really remove any enum entries where we depend on the order which is propagated around the cluster because by removing it we would suddenly move everything after it one ordinal down etc ... Also nodetool stuff, mbeans, configs which have "@Replaces" on them etc . If it is very cheap to keep it there / if it just calls another, non-deprecated method etc, I would just keep it there forever. The only stuff I really see as something eligible for actual removal is internal-only stuff - if we remove it, nobody really notices. We can also contemplate a removal when there is clearly a superior solution and a user is strongly recommended to use it instead. Even then it would be probably more appropriate to log a warning etc. as Josh suggested. I think there is really no silver bullet when it comes to what to remove / not remove and consulting that with a ML is strongly recommended. (1) https://lists.apache.org/thread/cxmgwcmo4tc03lg4yosf6o0xln61vyjf (2) https://lists.apache.org/thread/6hh7vct5bmcpbm47262mfm8xfnq8d3wm (3) https://issues.apache.org/jira/browse/CASSANDRA-18938 On Tue, Apr 22, 2025 at 3:49 AM Joseph Lynch <joe.e.ly...@gmail.com> wrote: > On Mon, Apr 21, 2025 at 9:20 AM Josh McKenzie <jmcken...@apache.org> > wrote: > >> Honestly, excepting thrift support I can't remember something we removed >> from the system in this way so a lot of this is perhaps premature process >> optimization. >> > > That is definitely fair, as long as we don't go deprecating things after a > single major release I'm happy, and I agree with Benedict the ideal is > "don't break users no matter how many major versions". Just doesn't seem > consistent to me with how we approach e.g. management interfaces. I at > least haven't experienced an upgrade yet where cassandra.yaml, jvm > properties, and JMX don't all experience some breakage, and the Thrift-CQL > migration is still infamous at Netflix for being one of the single most > expensive migrations we have ever done - so maybe I'm just biased heh. > > >> And I agree w/you here Benedict; given we can shim in translation from >> new functionality to continue to support previous APIs (thinking JMX as an >> example) there's really no hard requirement to deprecate or drop things >> excepting the maintenance cost, developer availability, and complexity >> burden of carrying some of these things forward. >> >> That said, I think Joey's framework makes intuitive sense so definitely >> worth exploring here and having in the archive so if we face some >> challenges in this department in the future we have some prior art and >> thinking to start from. >> > Happy to keep it in our "back pocket", agree starting with simple is > better. > > >> >> On Fri, Apr 18, 2025, at 4:17 PM, Benedict wrote: >> >> >> I’d much rather we agree to try NOT to deprecate or break things full >> stop. But once we decide there’s good reason to, I don’t think arbitrary >> lifetimes for a feature are really all that helpful are they? >> >> Arbitrary lifetimes are quite the problem for users when they are short, > I think it would hugely break trust if we just decided "well technically > it's a major release so we removed this thing that we deprecated a year > ago". I think we should be swift to deprecate (inform users we think > something is bad), or demote something back to experimental, but very slow > to remove. > > -Joey >
