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