My very own preference would be to actually focus on making 4.0 the release where have enough mechanism in place that no further ticket _have to_ wait for a major. That means at least making sure CASSANDRA-12042 makes it in, adding some proper versioning of schemas and CASSANDRA-8110.
If we had all that in place, I think no other would _have to_ be ready for 4.0 as it could then just be delayed to 4.2 (or whenever it's ready). If we don't do that, I'm willing to take bets that every new major release every year will be delayed cause "one more week, X is almost ready and we don't want to wait a year to get it in". On Wed, Jul 20, 2016 at 4:40 PM, 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 >
