[
https://issues.apache.org/jira/browse/CASSANDRA-18301?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17719841#comment-17719841
]
Andres de la Peña commented on CASSANDRA-18301:
-----------------------------------------------
Going back to the "compatibility mode" property idea, I think it would be a
property indicating the major Cassandra version we want to remain compatible
with. For example:
{code:java}
storage_compatibility_version: 4 # 4.0 and 4.1
{code}
It would be used to determine the default versions of sstables, commitlog,
hints, messaging, etc. All those would default to their latest supported
version on the Cassandra version we want to be compatible with. It would also
disable incompatible features, such as the extended expiration dates proposed
by CASSANDRA-14227.
Independently, we can have enable flags and specific configurations for
versions of components. For example:
{code:java}
storage_compatibility_version: 4
amazing_feature_added_on_cassandra_5_enabled: false
sstable_version:
format: big
version: nc
{code}
In that case, validation would reject all the configurations that clash with
the compatibility mode. For example, this config would be rejected:
{code:java}
storage_compatibility_version: 4
amazing_feature_added_on_cassandra_5_enabled: true
{code}
So the compatibility flag would we only used to set defaults and ensure that
users don't add any config that is going to prevent them from rolling back.
This way users could clearly express their desire to be backward compatible.
They wouldn't need to know what exact features and component versions break
compatibility.
At the same time, some new features could be enabled by default if the
compatibility version allows it. For example, tries could be the default in 5.0
if we are not in compatibility mode.
Rolling upgrades would start with the compatibility mode of their version of
origin. Then a second round of restarts could turnoff the compatibility mode
and enable any new opt-in features we want.
> 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
