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.

Reply via email to