Maybe for better understanding what we talk about, there is the PR which implements the changes suggested here (1)
It is clear that @Deprecated is not used exclusively on JMX / Configuration but we use it internally as well. This is a very delicate topic and we need to go, basically, one by one. I get that there might be some kind of a "nervousness" around this as we strive for not breaking it unnecessarily so there might be a lot of exceptions etc and I completely understand that but what I lack is clear visibility into what we plan to do with it (if anything). There is deprecated stuff as old as Cassandra 1.2 / 2.0 (!!!) and it is really questionable if we should not just get rid of that once for all. I am OK with keeping it there if we decide that, but we should provide some additional information like when it was deprecated and why it is necessary to keep it around otherwise the code-base will bloat and bloat ... (1) https://github.com/apache/cassandra/pull/2801/files ________________________________________ From: Mick Semb Wever <m...@apache.org> Sent: Friday, October 13, 2023 13:51 To: dev@cassandra.apache.org Subject: Re: [DISCUSS] putting versions into Deprecated annotations NetApp Security WARNING: This is an external email. Do not click links or open attachments unless you recognize the sender and know the content is safe. On Fri, 13 Oct 2023 at 13:07, Benjamin Lerer <ble...@apache.org<mailto:ble...@apache.org>> wrote: I was asking because outside of configuration parameters and JMX calls, the approach as far as I remember was to just change things without using an annotation. Yes, it is my understanding that such deprecation is only needed on methods/objects that belong to some API/SPI component of ours that requires compatibility. This is much more than configuration and JMX, and can be quite subtle in areas. A failed attempt I started at this is here: https://cwiki.apache.org/confluence/display/CASSANDRA/%28wip%29+Compatibility+Planning<https://nam04.safelinks.protection.outlook.com/?url=https%3A%2F%2Fcwiki.apache.org%2Fconfluence%2Fdisplay%2FCASSANDRA%2F%2528wip%2529%2BCompatibility%2BPlanning&data=05%7C01%7CStefan.Miklosovic%40netapp.com%7Cf0af5e7db5e9468faa8c08dbcbe2e9f3%7C4b0911a0929b4715944bc03745165b3a%7C0%7C0%7C638327947670748135%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C%7C&sdata=3363U2ZlI%2FasNF0NTMrdZ%2BogB%2FjigmCGt3zqRrIs99Q%3D&reserved=0> But there will also be internal methods/objects marked as deprecated that relate back to these compatibility concerns, annotated because their connection and removal might not be so obvious when the time comes.
