> > So long as non-user-visible improvements, including big ones, can still go > in 4.0 at that stage, I’m all for it.
My understanding is that after June 1st the 4.0 branch would be created and would be bugfix only. It's not really a feature freeze if you allow improvements after that, which is why they'd instead go to trunk. I'm also on the "too soon" train so pushing it back to August or so is desirable to me. On 5 April 2018 at 21:06, Aleksey Yeshchenko <alek...@apple.com> wrote: > So long as non-user-visible improvements, including big ones, can still go > in 4.0 at that stage, I’m all for it. > > — > AY > > On 5 April 2018 at 21:14:03, Nate McCall (zznat...@gmail.com) wrote: > > >>> My understanding, from Nate's summary, was June 1 is the freeze date > for > >>> features. I expect we would go for at least 4 months (if not longer) > >>> testing, fixing bugs, early dogfooding, and so on. I also equated June > 1 > >>> with the data which we would create a 'cassandra-4.0' branch, and thus > the > >>> merge order becomes: 3.0->3,11->4.0->trunk. > > This^ (apologies - 'freeze for alpha' was a bit open for interpretation :) > > The idea of making this point in time the 4.0 branch date and merge > order switch is a good one. > > Can we move our gelling consensus here towards this goal? > > --------------------------------------------------------------------- > To unsubscribe, e-mail: dev-unsubscr...@cassandra.apache.org > For additional commands, e-mail: dev-h...@cassandra.apache.org > >
