> If some piece of code is not used anymore then simplifying the code is the > best thing to do In the case of unused / unreferenced, sure. In the case of "other things use this but we shouldn't add any more dependencies on this because we need to remove it", a @Deprecated annotation w/version, reason, etc could be pretty useful.
Also - my instinct is that we have a lot of stuff in our ecosystem that depends on public methods in the codebase (I assume sidecar, bulk writer / reader, CDC clients though I tried to provide a formal API there, etc. etc) and I for one would be receptive to discussions on dev@ for the things people in the ecosystem have taken dependencies on so we can discuss whether or not to a) formally support those, and/or b) wrap an actual API around them so we can decouple those signatures from implementation. Our lack of rigor around what's a public API and what's not combined with our historic default posture of "none of it's an API, if you depend on it it's on you and we'll break it, also we don't provide many public extension points nor do we provide more than the core functionality of the DB in our ecosystem so have fun" *may not be* the optimal posture for us in terms of ecosystem adoption + long-term maintenance burden. I realize we've done this in the name of us being able to be as productive as possible working on the core DB itself, but I'm not entirely convinced it's actually the most productive path tbh. Go slow to go fast, invest to reap returns, etc. On Fri, Oct 13, 2023, at 9:16 AM, Miklosovic, Stefan via dev wrote: > 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. >
