> > In thinking about this, what is stopping us from branching 4.0 a lot > sooner? Like now-ish? This will let folks start hacking on trunk with > new stuff, and things we've gotten close on can still go in 4.0
Agree with Jeff here that this is not necessary. The branch point should be the feature freeze point. What's a reasonable alternative / compromise for this? And what > non-disruptive-but-still-large patches are in flight that we would want to > delay the line in the sand for? Seeing as we are now back to where we started (because this was inevitable) I'll start listing issues again. If we got this worked up over the release back when I started this thread, June 1 probably would have been enough warning for everyone to be happy. I started it the way I did so that we avoided all the needless debate, but we went there anywhere. Let's also not pretend that "we can drop 4.1 anytime", it will be exactly as controversial as 4.0 and require as much time, discussion, validation, and testing to get it out the window. I'd be expecting *at the earliest* that 4.1 landed in Q4 2019. I also find the whole "only drop large features at the start of a branch" curious. It's not like trunk has been verified in the meantime (ccm doesn't count), and anything new that's been introduced should have tests associated with it. As far as I'm aware, trunk is incredibly broken if you consider the current testing environment, and we'll have to fix that prior to releasing anything real. The point of a feature freeze is that you then spend a lot of time validating, testing, and fixing after the freeze but before you do the release. You're not in some great rush to release after the freeze. The point of a feature freeze isn't to have all your features in months/years before the freeze, it's just meant to stop you from implementing more features while you fix existing issues. I do understand the reluctance though, based on the history of the project. Tick-tock consisted of almost no follow up testing and validation, and 3.0 wasn't much better - but I think it's still reasonable to give a proper validation/testing strategy a chance, testing in our own environments and actually making all the utests+dtests work. Anyway, back to things which I think should land in 4.0 but have been in the works for a long time: RangeAwareCompaction - CASSANDRA-10540 <https://issues.apache.org/jira/browse/CASSANDRA-10540> We've seen *many* use cases that could benefit from this, and it's also good for fixing some of the serious problems with vnodes, repairs, and streaming. Despite the lack of action I don't think it's far from being finished, but with a June 1 deadline it's probably unlikely. Large partition improvements - CASSANDRA-9754 <https://issues.apache.org/jira/browse/CASSANDRA-9754> I know this is a much awaited feature for a fair few users, but mostly it will make operator life a lot easier. I look forward to the day where a user can't kill their cluster by reading a few large partitions. Idempotent DDL - CASSANDRA-13426 <https://issues.apache.org/jira/browse/CASSANDRA-13426> This will be handy but is really more important for CASSANDRA-10699 <https://issues.apache.org/jira/browse/CASSANDRA-10699> (which probably won't make it into 4.0). More importantly, as I already noted, there's a large backlog of patches to review that we simply won't get to before June 1st (this includes some fairly large patches as well, like the pluggable storage refactors). Side note June 1st puts us almost 2 years from our last feature release (3.10, Oct 2016) - not "almost a year"/a year/around a year. On 10 April 2018 at 22:34, Jeff Jirsa <jji...@gmail.com> wrote: > Seriously, what's the rush to branch? Do we all love merging so much we > want to do a few more times just for the sake of merging? If nothing > diverges, there's nothing gained from the branch, and if it did diverge, we > add work for no real gain. > > Beyond that, I still don't like June 1. Validating releases is hard. It > sounds easy to drop a 4.1 and ask people to validate again, but it's a hell > of a lot harder than it sounds. I'm not saying I'm a hard -1, but I really > think it's too soon. 50'ish days is too short to draw a line in the sand, > especially as people balance work obligations with Cassandra feature > development. > > > > > On Tue, Apr 10, 2018 at 3:18 PM, Nate McCall <zznat...@gmail.com> wrote: > > > A lot of good points and everyone's input is really appreciated. > > > > So it sounds like we are building consensus towards June 1 for 4.0 > > branch point/feature freeze and the goal is stability. (No one has > > come with a hard NO anyway). > > > > I want to reiterate Sylvain's point that we can do whatever we want in > > terms of dropping a new feature 4.1/5.0 (or whatev.) whenever we want. > > > > In thinking about this, what is stopping us from branching 4.0 a lot > > sooner? Like now-ish? This will let folks start hacking on trunk with > > new stuff, and things we've gotten close on can still go in 4.0 > > (Virtual tables). I guess I'm asking here if we want to disambiguate > > "feature freeze" from "branch point?" I feel like this makes sense. > > > > --------------------------------------------------------------------- > > To unsubscribe, e-mail: dev-unsubscr...@cassandra.apache.org > > For additional commands, e-mail: dev-h...@cassandra.apache.org > > > > >
