I’d strike CASSANDRA-10383 off the list - there is no way it’s a blocker for anything.
As for 9424, unless I die unexpectedly *and* nobody else picks up the work, it should be fine for Nov. Don’t see anything missing from the list. -- AY On 20 July 2016 at 15:59:34, 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 >
