[ 
https://issues.apache.org/jira/browse/CASSANDRA-18912?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17774422#comment-17774422
 ] 

Stefan Miklosovic edited comment on CASSANDRA-18912 at 10/12/23 10:47 AM:
--------------------------------------------------------------------------

[~mmuzaf]

commitlog_periodic_queue_size was stopped to be used in (1) The last time it 
was used was in 2.0.17. In 2.1.0-beta1 it is not used anymore. So I think that 
it is deprecated since 2.1.

(1) 
https://github.com/apache/cassandra/commit/22e18f5a348a911f89deed9f9984950de451d28a


was (Author: smiklosovic):
[~mmuzaf]

commitlog_periodic_queue_size was stopped to be used in (1) The last time it 
was used was in 2.0.17. In 2.1.0-beta1 it is not used anymore. So I think that 
it is deprecated since 2.1.0.

(1) 
https://github.com/apache/cassandra/commit/22e18f5a348a911f89deed9f9984950de451d28a

> Specify "since" in all Deprecated annotations
> ---------------------------------------------
>
>                 Key: CASSANDRA-18912
>                 URL: https://issues.apache.org/jira/browse/CASSANDRA-18912
>             Project: Cassandra
>          Issue Type: Improvement
>          Components: Legacy/Core
>            Reporter: Stefan Miklosovic
>            Assignee: Maxim Muzafarov
>            Priority: Normal
>          Time Spent: 0.5h
>  Remaining Estimate: 0h
>
> It would be great if we introduced in 5.0 a change in Deprecated annotations 
> like this:
> {code}
> @Deprecated(since = "4.0")
> {code}
> or 
> {code}
> @Deprecated(since = "3.11")
> {code}
> The reasoning behind this is that as of now, it is pretty cumbersome to 
> figure out what can be removed on the next major version. It has to be, 
> basically, done manually every time.
> There is also this parameter available:
> {code}
> @Deprecated(forRemoval = true / false)
> {code}
> which indicates whether the annotated element is subject to removal in a 
> future version so we do not need to think about this every time if it is 
> eligible for deletion in a next major or not.
> We could then have a check which would ensure that we are not releasing a 
> next major with some deprecations introduced two majors before.



--
This message was sent by Atlassian Jira
(v8.20.10#820010)

---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]

Reply via email to