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
