[
https://issues.apache.org/jira/browse/CASSANDRA-18912?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17781690#comment-17781690
]
Michael Semb Wever edited comment on CASSANDRA-18912 at 11/1/23 10:29 AM:
--------------------------------------------------------------------------
> That is all fine.
I'm not sure it is.
Take for example in …io.sstab.le.format.Version
{code}
/**
* @deprecated it is replaced by {@link #hasImprovedMinMax()} since 'nc'
and to be completetly removed since 'oa'
*/
/** @deprecated See CASSANDRA-18134 */
@Deprecated(since = "5.0")
public abstract boolean hasAccurateMinMax();
{code}
This inaccurately assumes that 5.0 doesn't use nc.
If the user is running with storage_compatibility_mode= CASSANDRA_4 (which is
the default in 5.0 and 5.1) then we are using the 'nb' format. That is, 'nb'
remains the default format in 5.0 and 5.1. Deprecating it like this doesn't
feel correct to me (though this can be opinion).
Even if it were not the default for storage_compatibility_mode, it's still a
legit option, and I would still question the deprecation of it.
I would agree that anything related to format versions earlier than 'nb' from
5.0 code can be considered deprecated. (But not removal until project agreement
to remove that format version, which we are aiming not to do.)
was (Author: michaelsembwever):
> That is all fine.
I'm not sure it is.
Take for example in …io.sstab.le.format.Version
{code}
/**
* @deprecated it is replaced by {@link #hasImprovedMinMax()} since 'nc'
and to be completetly removed since 'oa'
*/
/** @deprecated See CASSANDRA-18134 */
@Deprecated(since = "5.0")
public abstract boolean hasAccurateMinMax();
{code}
This inaccurately assumes that 5.0 doesn't use nc.
If the user is running with storage_compatibility_mode= CASSANDRA_4 (which is
the default in 5.0 and 5.1) then we are using the 'nb' format. That is, 'nb'
remains the default format in 5.0 and 5.1. Deprecated it like this doesn't feel
correct to me (though this can be opinion).
Even if it were not the default for storage_compatibility_mode, it's still a
legit option, and I would still question the deprecation of it.
I would agree that anything related to format versions earlier than 'nb' from
5.0 code can be considered deprecated. (But not removal until project agreement
to remove that format version, which we are aiming not to do.)
> 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]
