[
https://issues.apache.org/jira/browse/CASSANDRA-18301?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17704806#comment-17704806
]
Andres de la Peña commented on CASSANDRA-18301:
-----------------------------------------------
{quote}{quote} I remember there is sthg in Gossip to check the version of the
whole cluster.
{quote}{quote}
There are some methods in {{Gossiper}} for this, like {{{}getMinVersion{}}},
{{{}hasMajorVersion3Nodes{}}}, etc.
I guess we would need to extend those to propagate the compatibility mode, or
perhaps directly declare the node to be on that version, not sure. So a
coordinator rejects large deletion times if there are nodes that aren't on 5.0,
or that are in 5.0 configured to be compatible with an older version.
I don't think we need a feature flag for the extended deletion times if we have
that compatibility mode. I mean, the range of representation of deletion times
doesn't seem something to be turning on and off at will. I think we only need
to avoid it during upgrades.
> Let the user select the sstable version to write
> ------------------------------------------------
>
> Key: CASSANDRA-18301
> URL: https://issues.apache.org/jira/browse/CASSANDRA-18301
> Project: Cassandra
> Issue Type: New Feature
> Components: Local/Config, Local/SSTable
> Reporter: Jacek Lewandowski
> Assignee: Jacek Lewandowski
> Priority: Normal
>
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
---------------------------------------------------------------------
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org
