[
https://issues.apache.org/jira/browse/CASSANDRA-18912?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17781647#comment-17781647
]
Michael Semb Wever edited comment on CASSANDRA-18912 at 11/1/23 8:41 AM:
-------------------------------------------------------------------------
We've added since with version numbers to deprecations that are related to
sstable format versions. I think this is a mistake.
We have no policy in place for removing sstable format versions (_offline
compatibility_ vs _online upgrade compatibility_), see CASSANDRA-18312.
And with the addition of the storage_compatibility_mode yaml option we have to
consider past sstable formats as still in use in newer clusters. Though, the
introduction of the option bound the lowest format version to 'nb' (see
CASSANDRA-14227).
was (Author: michaelsembwever):
We're added since with version numbers to deprecations that are related to
sstable format versions. I think this is a mistake.
We have no policy in place for removing sstable format versions (_offline
compatibility_ vs _online upgrade compatibility_), see CASSANDRA-18312.
And with the addition of the storage_compatibility_mode yaml option we have to
consider past sstable formats as still in use in newer clusters. Though, the
introduction of the option bound the lowest format version to 'nb' (see
CASSANDRA-14227).
> 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.1
>
> 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]
