I think the source code can describe the intention better than words :-) The link to our Code Style with a discussion "summary": https://github.com/apache/cassandra-website/pull/245/files
The link to the pull request with the proposed changes (only "since" added and description): https://github.com/apache/cassandra/pull/2801/files On Fri, 13 Oct 2023 at 14:45, Benjamin Lerer <b.le...@gmail.com> wrote: > > 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.
