On Thu, Jul 21, 2016 at 4:38 PM, 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). > I don't think we ever agreed that being able to only make *any* kind of change to the intra-node protocol (to take that example) was a good thing. We merely agreed that this was kind of necessary due to the problem I'm suggesting we tackle (and some other we already tackled). That, and the fact that until tick-tock we were supposed to add feature only in major releases in the first place. In tick-tock, every feature release is kind of a major, and the fact we have to wait on some "super"-major for some issue is wrong. > > 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's exactly what I'm suggesting, and I'd be somewhat surprised we don't want to because I'm convinced it's the right thing to do :) > > 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 > > > > > >
