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.

Is this different from what others are thinking? I'm open to shifting the
actual date, but what about the rest?


On Thu, Apr 5, 2018 at 11:39 AM, Aleksey Yeshchenko <alek...@apple.com>
wrote:

> June feels a bit too early to me as well.
>
> I personally would go prefer end of August / beginning of September.
>
> +1 to the idea of having a fixed date, though, just not this one.
>
> —
> AY
>
> On 5 April 2018 at 19:20:12, Stefan Podkowinski (s...@apache.org) wrote:
>
> June is too early.
>
>
> On 05.04.18 19:32, Josh McKenzie wrote:
> > Just as a matter of perspective, I'm personally mentally diffing from
> > when 3.0 hit, not 3.10.
> >
> >> commit 96f407bce56b98cd824d18e32ee012dbb99a0286
> >> Author: T Jake Luciani <j...@apache.org>
> >> Date: Fri Nov 6 14:38:34 2015 -0500
> >> 3.0 release versions
> > While June feels close to today relative to momentum for a release
> > before this discussion, it's certainly long enough from when the
> > previous traditional major released that it doesn't feel "too soon" to
> > me.
> >
> > On Thu, Apr 5, 2018 at 12:46 PM, sankalp kohli <kohlisank...@gmail.com>
> wrote:
> >> We can take a look on 1st June how things are then decide if we want to
> >> freeze it and whats in and whats out.
> >>
> >> On Thu, Apr 5, 2018 at 9:31 AM, Ariel Weisberg <ar...@weisberg.ws>
> wrote:
> >>
> >>> Hi,
> >>>
> >>> +1 to having a feature freeze date. June 1st is earlier than I would
> have
> >>> picked.
> >>>
> >>> Ariel
> >>>
> >>> On Thu, Apr 5, 2018, at 10:57 AM, Josh McKenzie wrote:
> >>>> +1 here for June 1.
> >>>>
> >>>> On Thu, Apr 5, 2018 at 9:50 AM, Jason Brown <jasedbr...@gmail.com>
> >>> wrote:
> >>>>> +1
> >>>>>
> >>>>> On Wed, Apr 4, 2018 at 8:31 PM, Blake Eggleston <
> beggles...@apple.com>
> >>>>> wrote:
> >>>>>
> >>>>>> +1
> >>>>>>
> >>>>>> On 4/4/18, 5:48 PM, "Jeff Jirsa" <jji...@gmail.com> wrote:
> >>>>>>
> >>>>>> Earlier than I’d have personally picked, but I’m +1 too
> >>>>>>
> >>>>>>
> >>>>>>
> >>>>>> --
> >>>>>> Jeff Jirsa
> >>>>>>
> >>>>>>
> >>>>>> > On Apr 4, 2018, at 5:06 PM, Nate McCall <zznat...@gmail.com>
> >>>>> wrote:
> >>>>>> >
> >>>>>> > Top-posting as I think this summary is on point - thanks,
> >>> Scott!
> >>>>> (And
> >>>>>> > great to have you back, btw).
> >>>>>> >
> >>>>>> > It feels to me like we are coalescing on two points:
> >>>>>> > 1. June 1 as a freeze for alpha
> >>>>>> > 2. "Stable" is the new "Exciting" (and the testing and
> >>> dogfooding
> >>>>>> > implied by such before a GA)
> >>>>>> >
> >>>>>> > How do folks feel about the above points?
> >>>>>> >
> >>>>>> >
> >>>>>> >> Re-raising a point made earlier in the thread by Jeff and
> >>> affirmed
> >>>>>> by Josh:
> >>>>>> >>
> >>>>>> >> –––
> >>>>>> >> Jeff:
> >>>>>> >>>> A hard date for a feature freeze makes sense, a hard date
> >>> for a
> >>>>>> release
> >>>>>> >>>> does not.
> >>>>>> >>
> >>>>>> >> Josh:
> >>>>>> >>> Strongly agree. We should also collectively define what
> >>> "Done"
> >>>>>> looks like
> >>>>>> >>> post freeze so we don't end up in bike-shedding hell like we
> >>> have
> >>>>>> in the
> >>>>>> >>> past.
> >>>>>> >> –––
> >>>>>> >>
> >>>>>> >> Another way of saying this: ensuring that the 4.0 release is
> >>> of
> >>>>>> high quality is more important than cutting the release on a
> specific
> >>>>> date.
> >>>>>> >>
> >>>>>> >> If we adopt Sylvain's suggestion of freezing features on a
> >>>>> "feature
> >>>>>> complete" date (modulo a "definition of done" as Josh suggested),
> >>> that
> >>>>> will
> >>>>>> help us align toward the polish, performance work, and dog-fooding
> >>> needed
> >>>>>> to feel great about shipping 4.0. It's a good time to start thinking
> >>>>> about
> >>>>>> the approaches to testing, profiling, and dog-fooding various
> >>>>> contributors
> >>>>>> will want to take on before release.
> >>>>>> >>
> >>>>>> >> I love how Ben put it:
> >>>>>> >>
> >>>>>> >>> An "exciting" 4.0 release to me is one that is stable and
> >>> usable
> >>>>>> >>> with no perf regressions on day 1 and includes some of the
> >>> big
> >>>>>> >>> internal changes mentioned previously.
> >>>>>> >>>
> >>>>>> >>> This will set the community up well for some awesome and
> >>> exciting
> >>>>>> >>> stuff that will still be in the pipeline if it doesn't make
> >>> it to
> >>>>>> 4.0.
> >>>>>> >>
> >>>>>> >> That sounds great to me, too.
> >>>>>> >>
> >>>>>> >> – Scott
> >>>>>> >
> >>>>>> > ------------------------------------------------------------
> >>>>>> ---------
> >>>>>> > 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
> >>>>>>
> >>>>>>
> >>>>>>
> >>>>>>
> >>>>>>
> >>>>>> ------------------------------------------------------------
> >>> ---------
> >>>>>> 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
> >>>
> >>>
> > ---------------------------------------------------------------------
> > 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
>
>

Reply via email to