I forgot the round #3. That would consist of an ant task which would scan the source. Since we enforced that each Deprecation annotation has to have its "since" on compile time, we can write a parser in that task which would tell you what you have to do in order to be sure that your next release will not contain any stuff which should not be there. E.g. when we release 6.0, all 4.0 stuff can go away etc ...
________________________________________ From: Miklosovic, Stefan via dev <dev@cassandra.apache.org> Sent: Friday, October 13, 2023 15:00 To: dev@cassandra.apache.org Cc: Miklosovic, Stefan 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. 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://github.com/apache/cassandra/pull/2801/files> ________________________________________ 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://cwiki.apache.org/confluence/display/CASSANDRA/%28wip%29+Compatibility+Planning><https://cwiki.apache.org/confluence/display/CASSANDRA/%28wip%29+Compatibility+Planning<https://cwiki.apache.org/confluence/display/CASSANDRA/%28wip%29+Compatibility+Planning>> 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.
