[
https://issues.apache.org/jira/browse/CASSANDRA-18912?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17776520#comment-17776520
]
Stefan Miklosovic edited comment on CASSANDRA-18912 at 10/18/23 7:05 AM:
-------------------------------------------------------------------------
j17 5.0
https://app.circleci.com/pipelines/github/instaclustr/cassandra/3347/workflows/47fab436-eb1a-4e14-a8c7-c8681475c447
j17 trunk
https://app.circleci.com/pipelines/github/instaclustr/cassandra/3349/workflows/4e1d5e11-92be-4815-90bf-1acc2bd9ca74
I dont think we need Java 11 here. This is literally just putting annotations
with comments into the code.
+1
was (Author: smiklosovic):
j17 5.0
https://app.circleci.com/pipelines/github/instaclustr/cassandra/3347/workflows/47fab436-eb1a-4e14-a8c7-c8681475c447
j17 trunk
https://app.circleci.com/pipelines/github/instaclustr/cassandra/3349/workflows/4e1d5e11-92be-4815-90bf-1acc2bd9ca74
I dont think we need Java 11 here. This is literally just putting annotations
with comments into the code.
> 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
> Labels: pull-request-available
> 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]