> I would like to propose a partial freeze of 5.0 in June
My .02:
+1 to:
* partial freeze on an agreed upon date w/agreed upon other things that can
optionally go in after
* setting a hard limit on when we ship from that frozen branch regardless of
whether the features land or not
-1 to:
* ever
I am +1 on a 5.0 branch freeze.
Kind Regards,
Brandon
On Fri, Mar 24, 2023 at 8:54 AM Benjamin Lerer wrote:
>>
>> Would that be a trunk freeze, or freeze of a cassandra-5.0 branch?
>
>
> I was thinking of a cassandra-5.0 branch freeze. So branching 5.0 and
> allowing only CEP-15 and 21 + bug fi
>
> Would that be a trunk freeze, or freeze of a cassandra-5.0 branch?
I was thinking of a cassandra-5.0 branch freeze. So branching 5.0 and
allowing only CEP-15 and 21 + bug fixes there.
Le ven. 24 mars 2023 à 13:55, Paulo Motta a
écrit :
> > I would like to propose a partial freeze of 5.0 in
> I would like to propose a partial freeze of 5.0 in June.
Would that be a trunk freeze, or freeze of a cassandra-5.0 branch? I agree
with a branch freeze, but not with trunk freeze.
I might work on small features after June and would be happy to delay
releasing these on 5.0+, but delaying merge
> I would like to propose a partial freeze of 5.0 in June.
>
…
>
This partial freeze will be valid for every new feature except CEP-21 and
> CEP-15.
>
+1
Thanks for summarising the thread this way Benjamin. This addresses my two
main concerns: letting the branch/release date slip too much into t
;>>> Hi,
>>>>>
>>>>> We shouldn't release just for releases sake. Are there enough new
>>>>> features and are they working well enough (quality!).
>>>>>
>>>>> The big feature from our perspective for 5.0 is ACCORD (
y working well enough (quality!).
>>>>
>>>> The big feature from our perspective for 5.0 is ACCORD (CEP-15) and I
>>>> would advocate to delay until this has sufficient quality to be in
>>>> production.
>>>>
>>>> Just because
would advocate to delay until this has sufficient quality to be in
>>>> production.
>>>>
>>>> Just because something is released doesn't mean anyone is gonna use it.
>>>> To add some operator perspective: Every time there is a new release we need
rman
*From:* Benedict
*Sent:* Wednesday, March 1, 2023 5:59 AM
*To:* dev@cassandra.apache.org
*Subject:* [EXTERNAL] Re: [DISCUSS] Next release date
It doesn’t look like we agreed to a policy of annual
branch dat
;> To add some operator perspective: Every time there is a new release we need
>>> to decide
>>> 1) are we supporting it
>>> 2) which other release can we deprecate
>>>
>>> and potentially migrate people - which is also a tough sell if there are
>
> Should we clarify that part first by getting an idea of the status of the
> different CEPs and other big pieces of work?
CEP-20 (dynamic data masking) should hopefully be ready by the end of this
month.
It's composed by seven small tickets. Five of those tickets are ready, and
two are under
> > > One place we've been weak historically is in distinguishing between
> > > tickets we consider "nice to have" and things that are "blockers". We
> > > don't have any metadata that currently distinguishes those two, so
> > > determining what our burndown leading up to 5.0 looks like is a lot
> We do have the metadata, but yes it requires some work…
My wording was poor; we have the *potential* to have this metadata, but to my
knowledge we don't have a muscle of consistently setting this, or any kind of
heuristic to determine when something should block a release or not. At least
on 4
>
> One place we've been weak historically is in distinguishing between
> tickets we consider "nice to have" and things that are "blockers". We don't
> have any metadata that currently distinguishes those two, so determining
> what our burndown leading up to 5.0 looks like is a lot more data massag
There is also this roadmap page but we haven’t updated it lately. It
contains still 4.1 updates from last year.
https://cwiki.apache.org/confluence/display/CASSANDRA/Roadmap
On Thu, 9 Mar 2023 at 13:51, Josh McKenzie wrote:
> Added an "Epics" quick filter; could help visualize what our high pri
Added an "Epics" quick filter; could help visualize what our high priority
features are for given releases:
https://issues.apache.org/jira/secure/RapidBoard.jspa?rapidView=484&quickFilter=2649
Our cumulative flow diagram of 5.0 related tickets is pretty large. Probably
not a great indicator for
>
> I've also found some useful Cassandra's JIRA dashboards for previous
> releases to track progress and scope, but we don't have anything
> similar for the next release. Should we create it?
> Cassandra 4.0GAScope
> Cassandra 4.1 GA scope
>
https://issues.apache.org/jira/secure/RapidBoard.jspa?
>>> 2) which other release can we deprecate
>>>
>>> and potentially migrate people - which is also a tough sell if there are no
>>> significant features and/or breaking changes. So from my perspective less
>>> frequent releases are better - after all we haven't got
support 4.1 🙂
>>
>> The 5.0 release is also coupled with deprecating 3.11 which is what a
>> significant amount of people are using - given 4.1 took longer I am not
>> sure how many people are assuming that 5 will be delayed and haven't made
>> plans (OpenJDK s
3.11 which is what a
> significant amount of people are using - given 4.1 took longer I am not
> sure how many people are assuming that 5 will be delayed and haven't made
> plans (OpenJDK support for 8 is longer than Java 17 🙂) . So being a bit
> more deliberate with releasing 5.0 a
ven 4.1 took longer I am not sure
> how many people are assuming that 5 will be delayed and haven't made plans
> (OpenJDK support for 8 is longer than Java 17 🙂) . So being a bit more
> deliberate with releasing 5.0 and having a longer beta phase are all things
> we should co
: Wednesday, March 1, 2023 5:59 AM
To: dev@cassandra.apache.org
Subject: [EXTERNAL] Re: [DISCUSS] Next release date
It doesn’t look like we agreed to a policy of annual branch dates, only annual
releases and that we would schedule this for 4.1 based on 4.0’s branch date.
Given this was the reasonin
22 matches
Mail list logo
