Ok, thanks Stefan I understand the context better now. Looking at the PR. Some make sense also for serialization reasons but some make no sense to me.
Le ven. 13 oct. 2023 à 14:26, Benjamin Lerer <b.le...@gmail.com> a écrit : > I’ve been told in the past not to remove public methods in a patch release >> though. >> > > Then I am curious to get the rationale behind that. If some piece of code > is not used anymore then simplifying the code is the best thing to do. It > makes maintenance easier and avoids mistakes. > Le ven. 13 oct. 2023 à 14:11, Miklosovic, Stefan via dev < > dev@cassandra.apache.org> a écrit : > >> 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. >> >
