There’s also: CASSANDRA-10520 Compressed writer and reader should support non-compressed data (changes sstable format) CASSANDRA-10383 Disable auto snapshot on selected tables (changes schema)
— Robert Stupp @snazy > On 21 Jul 2016, at 00:59, Jason Brown <jasedbr...@gmail.com> wrote: > > CASSANDRA-8457 - nio MessagingService. Patch is up and awaiting review > > On Wed, Jul 20, 2016 at 7:40 AM, Jonathan Ellis <jbel...@gmail.com> wrote: > >> The plan of record has been to ship 4.0 in November, 12 months after 3.0. >> But, there are a number of features that are going to cause backwards >> incompatibility and if they miss 4.0 will need to wait for 5.0. Are any of >> these worth delaying 4.0 for? >> >> (Currently the plan is to have all of these ready for November, but let's >> get our backup plan figured out now, just in case. That way we don't have >> to make the decision at the last minute when everything feels like an >> emergency.) >> >> Some candidates that might be worth delaying the release for: >> >> - "Birch" trees for the primary key index >> <https://issues.apache.org/jira/browse/CASSANDRA-9754>. Changes the >> format of data on disk so automatically in the "dot zero" category. >> - Decouple messaging protocol versioning >> <https://issues.apache.org/jira/browse/CASSANDRA-12042>. This would >> allow us to change the intra-node protocol on a per-message basis, which >> gives us more flexibility with compatibility. Currently any change >> drops >> us into the "no schema changes until everyone is upgraded" world which >> effectively rules out making any improvements across tick-tock releases. >> - Allow dropping COMPACT STORAGE flag >> <https://issues.apache.org/jira/browse/CASSANDRA-10857>. This is what >> makes it possible to remove the deprecated Thrift support. >> - Schema rearchitecture >> <https://issues.apache.org/jira/browse/CASSANDRA-9424>. Can we live >> without safe and programatic CREATE and ALTER for another year? >> >> -- >> Jonathan Ellis >> Project Chair, Apache Cassandra >> co-founder, http://www.datastax.com >> @spyced >>
