I think moving it to August/Sept will be better On Apr 10, 2018, at 17:24, Josh McKenzie <jmcken...@apache.org> wrote:
>> >> 50'ish days is too short to draw a line in the sand, >> especially as people balance work obligations with Cassandra feature >> development. > > 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? > >> On Tue, Apr 10, 2018 at 6:34 PM, 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 >>> >>> >> --------------------------------------------------------------------- To unsubscribe, e-mail: dev-unsubscr...@cassandra.apache.org For additional commands, e-mail: dev-h...@cassandra.apache.org
