[
https://issues.apache.org/jira/browse/CASSANDRA-18912?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
miklosovic updated CASSANDRA-18912:
-----------------------------------
Attachment: signature.asc
That is all fine. Adding "since" is technically correct, I think it was truly
firstly deprecated in so and so version.
There is the second parameter called "forRemoval" which is by default "false"
(check the source of Deprecated / javadoc). That means we ideally put
"forRemoval = true / false" explicitly to all these annotations.
For now, as "forRemoval" is false by default, you can look at it as it is not
eligible for deletion.
We are in the process of mapping this and getting rid of deprecations I dont
have a problem to put forRemoval = true / false everywhere. We just have to
decide which is which. For now, in all these alphas they are there like
"forRemoval = false". Having "since" in annotation does not necessarily mean we
go to remove it. That's why I am sending out the emails to ML about that.
Sent from ProtonMail mobile
\
> 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
> Fix For: 5.0-alpha2, 5.0, 5.1
>
> Attachments: signature.asc
>
> 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]
