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
