OK. So here we are ... round 1 will be to map how bad it is, round 2 will be the removal of what should not be there. I am not sure if round 2 will be done before 5.0 is out (that would be ideal, to release 5.0 without a lot of baggage like that) so it will be better if we split this effort into two parts.
________________________________________ From: Benjamin Lerer <b.le...@gmail.com> Sent: Friday, October 13, 2023 14:45 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. 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<mailto: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<mailto: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<https://nam04.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2Fapache%2Fcassandra%2Fpull%2F2801%2Ffiles&data=05%7C01%7CStefan.Miklosovic%40netapp.com%7C13df2c6740cf4bb2832e08dbcbea5924%7C4b0911a0929b4715944bc03745165b3a%7C0%7C0%7C638327979607217759%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C%7C&sdata=A8pSKjQJL894lvHB0RYn32U4t8cAIcA36XZ49njMmyI%3D&reserved=0> ________________________________________ From: Mick Semb Wever <m...@apache.org<mailto:m...@apache.org>> Sent: Friday, October 13, 2023 13:51 To: dev@cassandra.apache.org<mailto: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><mailto: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%7C13df2c6740cf4bb2832e08dbcbea5924%7C4b0911a0929b4715944bc03745165b3a%7C0%7C0%7C638327979607217759%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C%7C&sdata=gWRK8YI0F%2Bn%2BX402hGvQxKF%2FJPXyhzuQMS52IjoxQOw%3D&reserved=0><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<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%7C13df2c6740cf4bb2832e08dbcbea5924%7C4b0911a0929b4715944bc03745165b3a%7C0%7C0%7C638327979607217759%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C%7C&sdata=gWRK8YI0F%2Bn%2BX402hGvQxKF%2FJPXyhzuQMS52IjoxQOw%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.
