How I look at it is that if we clearly and explicitly specify "since" and 
"forRemoval" for all of our @Deprecated annotations, then it does really matter 
who is the consumer of that?

Imagine a scenario where there is some tool which puts cassandra-all on the 
class path and then it cherry-picks this and that from it. Once it is 
deprecated and it is explicitly visible since when and there is a clear policy 
what will happen with it in next release (some documetation on the website or 
similar), then is it really us to blame that their code will broke in the next 
release if they don't clean it up? I don't think so. External tooling should 
not take it for granted that what is there will be there for ever and what is 
deprecated will have its expiration date, again, if not explicitly said 
otherwise.

________________________________________
From: Josh McKenzie <jmcken...@apache.org>
Sent: Friday, October 13, 2023 15:36
To: dev
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.



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<mailto:dev@cassandra.apache.org>>
Sent: Friday, October 13, 2023 15:00
To: dev@cassandra.apache.org<mailto: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<mailto:b.le...@gmail.com>>
Sent: Friday, October 13, 2023 14:45
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.



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><mailto: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><mailto: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%7C9693e079db614fd5200708dbcbf2311d%7C4b0911a0929b4715944bc03745165b3a%7C0%7C0%7C638328013291548579%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C%7C&sdata=eDXmpk7AvWjHjbjS4KsmZbzkwT7RhNPVoJbnMlLZFQA%3D&reserved=0><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%7C9693e079db614fd5200708dbcbf2311d%7C4b0911a0929b4715944bc03745165b3a%7C0%7C0%7C638328013291548579%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C%7C&sdata=eDXmpk7AvWjHjbjS4KsmZbzkwT7RhNPVoJbnMlLZFQA%3D&reserved=0>>

________________________________________
From: Mick Semb Wever 
<m...@apache.org<mailto:m...@apache.org><mailto:m...@apache.org<mailto:m...@apache.org>>>
Sent: Friday, October 13, 2023 13:51
To: 
dev@cassandra.apache.org<mailto:dev@cassandra.apache.org><mailto: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>><mailto: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%7C9693e079db614fd5200708dbcbf2311d%7C4b0911a0929b4715944bc03745165b3a%7C0%7C0%7C638328013291704815%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C%7C&sdata=FeHEgDdfOy7nBc0QSxyr01YhyniwtBILr02b08AWhnQ%3D&reserved=0><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%7C9693e079db614fd5200708dbcbf2311d%7C4b0911a0929b4715944bc03745165b3a%7C0%7C0%7C638328013291704815%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C%7C&sdata=FeHEgDdfOy7nBc0QSxyr01YhyniwtBILr02b08AWhnQ%3D&reserved=0>><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%7C9693e079db614fd5200708dbcbf2311d%7C4b0911a0929b4715944bc03745165b3a%7C0%7C0%7C638328013291704815%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C%7C&sdata=FeHEgDdfOy7nBc0QSxyr01YhyniwtBILr02b08AWhnQ%3D&reserved=0><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%7C9693e079db614fd5200708dbcbf2311d%7C4b0911a0929b4715944bc03745165b3a%7C0%7C0%7C638328013291704815%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C%7C&sdata=FeHEgDdfOy7nBc0QSxyr01YhyniwtBILr02b08AWhnQ%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.


Reply via email to