> > 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. >
