> * Freeze cassandra-4.1 on may 1st
>
A feature freeze on the release branch is always implied.
And repeating, because it bugs me (and I just need to air it): we're
talking about this because we have not achieved a stable trunk this dev
cycle.
The 4.0 branch has remained very close, but trunk n
I agree with
* Fork may 1st
* Freeze cassandra-4.1 on may 1st
> On Mar 9, 2022, at 1:23 AM, Benjamin Lerer wrote:
>
> We also have the requirement that there will be no release without green CI.
> Do we cut a release branch on the 1st May if we don't yet have a green CI and
> can't be making
>
> We also have the requirement that there will be no release without green
> CI. Do we cut a release branch on the 1st May if we don't yet have a green
> CI and can't be making a cut off it?
I would propose to create the new branch on the 1st of May and consider it
feature freeze. We can then l
I tend to agree with Mick. We should have a bit of time to look around and
do a final cross check. Also, our CI is really painful these days and I am
not talking only about test failures, but infra.
On Tue, 8 Mar 2022 at 13:56, Mick Semb Wever wrote:
> We do not want to encourage/enable the rush
>
> We do not want to encourage/enable the rush to commit stuff before the 1st
> May cut-off. IMHO we should be comfortable leaning towards saving any
> significant commits for the next dev cycle.
>
> With sufficient testing added for a new feature, feature flags for
> optionality, and a window of
gt; wrote:
>> At the very least we should wait until the current issues with CI have
>> resolved, so that pending work can merge, before declaring any freeze.
>>
>> From: Mick Semb Wever
>> Date: Tuesday, 8 March 2022 at 15:13
>> To: dev@cassandra.apa
te: *Tuesday, 8 March 2022 at 15:13
> *To: *dev@cassandra.apache.org
> *Subject: *Re: [DISCUSS] Next release cut
>>
>> Should we plan some soft freeze before that?
>
>
> Good question! :-)
>
> We do not want to encourage/enable the rush to commit stuff before
At the very least we should wait until the current issues with CI have
resolved, so that pending work can merge, before declaring any freeze.
From: Mick Semb Wever
Date: Tuesday, 8 March 2022 at 15:13
To: dev@cassandra.apache.org
Subject: Re: [DISCUSS] Next release cut
Should we plan some
>
>
> Should we plan some soft freeze before that?
>
Good question! :-)
We do not want to encourage/enable the rush to commit stuff before the 1st
May cut-off. IMHO we should be comfortable leaning towards saving any
significant commits for the next dev cycle. How do we create the correct
incent
Cut branch and freeze May 1st
Goal to GA July 1st
We talking something like that ^ w/8 weeks to stabilize, clean up straggler
tests, and maybe do some fuzzing and property based testing against it?
On Tue, Mar 8, 2022, at 8:36 AM, Paulo Motta wrote:
> Thanks for bringing this topic for discussio
Thanks for bringing this topic for discussion Benjamin.
> The cassandra-4.0 branch was created on the 1st of May last year. So it
would make sense to do something similar this year. Does it sound
reasonable?
+1 to having a predictable release date and May 1st sounds good to me.
> Should we plan
Hi everybody,
We discussed cutting the next release in May but did not provide more
clarity about it.
The cassandra-4.0 branch was created on the 1st of May last year. So it
would make sense to do something similar this year. Does it sound
reasonable?
Should we plan some soft freeze before that?
D
+1
On Mon, Jan 3, 2022 at 1:21 PM Brandon Williams wrote:
> +1 to 4.1 in May.
>
> On Tue, Dec 14, 2021, 6:46 AM Mick Semb Wever wrote:
>
>> > We cut 4.0 in May and released it in July. It is difficult to plan for a
>> release date so we should probably agree on the cut date. One year after
>> 4
+1 to 4.1 in May.
On Tue, Dec 14, 2021, 6:46 AM Mick Semb Wever wrote:
> > We cut 4.0 in May and released it in July. It is difficult to plan for a
> release date so we should probably agree on the cut date. One year after
> 4.0 that would make us cut the new branch in May.
>
>
> This makes sens
+1 to 4.1 in May.
On Mon, Jan 3, 2022 at 12:58 PM David Capwell wrote:
> 4.1 target of may works for me, we may want to remove a few things in
> Config.java if not wrapped up on time (thinking track warnings and
> guardrails, though that should be handled by then)
>
> > On Dec 14, 2021, at 5:02
4.1 target of may works for me, we may want to remove a few things in
Config.java if not wrapped up on time (thinking track warnings and guardrails,
though that should be handled by then)
> On Dec 14, 2021, at 5:02 AM, Paulo Motta wrote:
>
> +1 to cut 4.1 in May. It would be great to attain th
+1 to cut 4.1 in May. It would be great to attain the yearly cut cadence if
possible.
Em ter., 14 de dez. de 2021 às 09:45, Mick Semb Wever
escreveu:
> > We cut 4.0 in May and released it in July. It is difficult to plan for a
> release date so we should probably agree on the cut date. One year
> We cut 4.0 in May and released it in July. It is difficult to plan for a
release date so we should probably agree on the cut date. One year after
4.0 that would make us cut the new branch in May.
This makes sense to me. The time between each rc1 cut is the only
thing we control. We want the rc1
Hi everybody,
I believe that we never really clarified when the next release should
happen. We agreed on a yearly frequency but did not go down on the details.
It might be worth it to clarify them so that we are sure that everybody is
on the same line.
We cut 4.0 in May and released it in July. I
19 matches
Mail list logo
