[
https://issues.apache.org/jira/browse/CASSANDRA-6570?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13868281#comment-13868281
]
Jonathan Ellis commented on CASSANDRA-6570:
-------------------------------------------
bq. 2.1 is an unusually good place to do this since AFAIK we haven't made any
other incompatible changes, e.g. to schema propagation.
... thinking about it more, it's also an unusually poor place since we got rid
of the two-pass compaction that the old format required for large rows.
I could see
# adding back precompacted row (which is at least relatively simple) and just
saying we won't compact 2.0-format rows larger than in_memory_compaction_limit
# or, adding back two-pass compaction
Is there a clever 80% solution I'm missing?
> Compatibility mode for 2.1
> --------------------------
>
> Key: CASSANDRA-6570
> URL: https://issues.apache.org/jira/browse/CASSANDRA-6570
> Project: Cassandra
> Issue Type: Task
> Components: Core
> Reporter: Jonathan Ellis
> Assignee: Marcus Eriksson
> Fix For: 2.1
>
>
> Upgrading to a new major Cassandra release is a big commitment, because once
> on a new version you can't downgrade again because we write new-version
> sstables.
> Let's add an option to write old-version sstables so that users can try
> upgrading a single 2.1 RC node in a 2.0 cluster with the safety net of being
> able to back it out if anything goes wrong.
--
This message was sent by Atlassian JIRA
(v6.1.5#6160)
