[
https://issues.apache.org/jira/browse/CASSANDRA-18301?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17704130#comment-17704130
]
Andres de la Peña commented on CASSANDRA-18301:
-----------------------------------------------
If I'm right CEP-17 added a new yaml property indicating whether big or bti
format should be used, called {{sstable_formats}}.
An upgrade from 5.0 to 6.0 will have that property too. So if the
"compatibility mode" property is set to stay compatible with 5.0, we should
produce the sstable format used for whatever big/bti choice is set in
{{sstable_formats}}.
If we are upgrading from 4.1 to 5.0 and the compatibility mode is set to 4.1,
we should reject a {{sstable_formats}} asking for bti, because that wasn't
present on 4.1.
So, in general when a "compatibility mode" property is set we should validate a
startup that the rest of the config and its feature flags are compatible with
that choice. Does it makes sense?
As for exact versions, I was thinking only on expressing it as compatibility
between majors. So we can use the compatibility property to make the upgrade to
a major equivalent to upgrading to a minor.
> 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
