On Thu, Jul 21, 2016 at 5:40 PM, Aleksey Yeschenko <alek...@apache.org> wrote:
> We don’t need to block 4.0 on #8110. > > What we need is to block those sstable-format related tickets on *either* > #8110 *or* 4.0. > You're right, I kind of listed the ticket a bit quickly. > > #8110 itself can go anywhere in 3.x or 4.x. > > -- > AY > > On 21 July 2016 at 15:38:58, Jason Brown (jasedbr...@gmail.com) wrote: > > Sylvain, > > In the large, yes, that is the best "have enough mechanism in place that no > further ticket _have to_ wait for a major", but many of the tickets we are > talking about makes changes to things we've all agreed can *only* happen at > majors, as per the > http://wiki.apache.org/cassandra/CompatibilityGuarantees > (changing the internode protocol, for instance). > > if we're willing to trade on those Guarantees, then sure, majors are just > bike shedding the version numbers, but I suspect we don't want to do that > ;) > > That being said, I completely understand the frustration of "one more week, > X is almost ready and we don't want to wait a year to get it in". I offer > two points, though: > 1) This is an open source project, with no real business requirements to > ship any version by any specific date. We want to ship often enough to be > relevant as a project/product, of course, but there's no financial or > business requirement to do so. > 2) We could have better planning as to what we actually want to ship in a > "version", or at least have some agreed upon mid- to long-term roadmap. > This would help focus the calendar and the project. Currently, it's largely > willy-nilly as to what ships when, and while tick-tock has introduced > regularity wrt release dates, there's not much that shapes what goes in > those releases. > > My two cents, > > -Jason > > > > On Thu, Jul 21, 2016 at 7:02 AM, Sylvain Lebresne <sylv...@datastax.com> > wrote: > > > 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 > > > > > >
