Thanks Caleb and JD, I'm keen to see us move forward.
Josh,
I (and others) have expressed concern about trying to use dates, and
stating periods of time to achieve X, to work backwards from a desired GA
date. Dates always slip, and we don't have the evidence (beyond
the extreme of 6 months for 4
Let me try to break this down another way:
I see a few competing concerns, each with QA related time requirements
(asserting 8 weeks minimum, 16 weeks maximum we should plan for to stabilize a
GA):
1. A freeze to a branch to stabilize for release (8-16 weeks of QA required
after we branch)
2.
I'm going to repeat the point from my own thread: rather than thinking of
this as some kind of concession to two exceptional CEPs, could we rather
take the point of view that they get their own space and time precisely
because they are large and invasive and both the merge and testing of them
will
That said I’m not opposed to Mick’s proposal. In Apache terms I am -0 on the proposal. So no need to try and convince me. If others think it is the way forward let’s go with it.On Apr 18, 2023, at 1:48 PM, J. D. Jordan wrote:I also don’t really see the value in “freezing with exceptions for two
I also don’t really see the value in “freezing with exceptions for two giant changes to come after the freeze”.-JeremiahOn Apr 18, 2023, at 1:08 PM, Caleb Rackliffe wrote:> Caleb, you appear to be the only one objecting, and it does not appear that you have made any compromises in this thread.All
> Caleb, you appear to be the only one objecting, and it does not appear
that you have made any compromises in this thread.
All I'm really objecting to is making special exceptions for particular
CEPs in relation to our freeze date. In other words, let's not have a
pseudo-freeze date and a "real"
I forgot one last night:
>From Benjamin we have a question that I think went unanswered?
*> Should it not facilitate the work if the branch stops changing heavily?*
This is IMO a good perspective. To me it seems weird to be too hung up on a
"hard limit" on a specific day, when we are talking abo
Finally, I expect most Europeans to be on vacation 33% of that time. Non-Europeans may want to try it too!The more northerly Europeans maybe :)On 18 Apr 2023, at 01:24, Henrik Ingo wrote:Trying to collect a few loose ends from across this thread> I'm receptive to another definition of "stabilize"
> If this is true, why do we even bother running any CI before the CEP-21
> merge? It will all be invalidated anyway, right?
I'm referring to manual validation or soak testing in qa environments rather
than automated. Just because a soft-frozen branch without those features works
in QA doesn't m
Trying to collect a few loose ends from across this thread
*> I'm receptive to another definition of "stabilize", *
I think the stabilization period implies more than just CI, which is mostly
a function of unit tests working correctly. For example, at Datastax we
have run a "large scale" test wit
>
> My personal .02: I think we should consider branching 5.0 September 1st.
> That gives us basically 12 weeks for folks to do their testing and for us
> to stabilize anything that's flaky in circle or regressed in ASF CI.
>
I'm not for this, sorry. I see the real risk here of there being no GA
> WFM, if that means we branch there and anything not already merged has to wait
I think there might be value in us exploring the "how we cut snapshots" in
terms of allowing us to fast-follow for big features folks may want to get
their hands on. If we stick to the same "green circle no regressio
> My personal .02: I think we should consider branching 5.0 September 1st.
That gives us basically 12 weeks for folks to do their testing and for us
to stabilize anything that's flaky in circle or regressed in ASF CI.
WFM, if that means we branch there and anything not already merged has to
wait
> it's (b) for me, and everything minus 21 and 15 is defining enough to warrant
> the branching and a checkpoint where testing can start
Ok, I don't follow.
There's three different ways I can read what you're saying here:
1. "Everything we have targeting 5.x is substantial and we can branch when
> b.) Cut a 5.0 branch when the major release-defining element (maybe
> CEP-21?) merges to trunk, with the shared understanding (possibly what
> we're disagreeing about) that very little of what we need to test/de-risk
> is going to be inhibited by not cutting that branch earlier (and that
> certai
What I'm trying to propose is that we either...
a.) Pick the latest responsible (preserves our desired timeline for GA)
date to cut a 5.0 branch, and not let anything else in after, including
CEP-15/CEP-21.
b.) Cut a 5.0 branch when the major release-defining element (maybe
CEP-21?) merges to trun
I failed to address:
> - freeing up folk to start QA (that makes sense to start) immediately
I think there's a pre-freeze set of QA that makes sense to do and a
post-freeze. What we decide on mergeability of large bodies of work around that
branch date will inform what qualifies as a "freeze" in
So to bring us back to the goals and alignment here:
> With the following intentions:
> - moving towards the goal of annual releases, with a cadence 12±3 months
> apart,
> - the branch to GA period being 2-3 months,
> - avoiding any type of freeze on trunk,
> - getting a release out by December's
On Mon, 17 Apr 2023 at 19:31, Caleb Rackliffe
wrote:
> ...or just cutting a 5.0 branch when CEP-21 is ready.
>
> There's nothing stopping us from testing JDK17 and TTL bits in trunk
> before that.
>
> On Mon, Apr 17, 2023 at 11:25 AM Caleb Rackliffe
> wrote:
>
>> > Once all CEPs except CEP-21 an
...or just cutting a 5.0 branch when CEP-21 is ready.
There's nothing stopping us from testing JDK17 and TTL bits in trunk before
that.
On Mon, Apr 17, 2023 at 11:25 AM Caleb Rackliffe
wrote:
> > Once all CEPs except CEP-21 and CEP-15 land we branch cassandra-5.0
>
> For the record, I'm not con
> Once all CEPs except CEP-21 and CEP-15 land we branch cassandra-5.0
For the record, I'm not convinced this is necessarily better than just
cutting a cassandra-5.0 branch on 1 October.
On Mon, Apr 17, 2023 at 2:30 AM Mick Semb Wever wrote:
> 2. When CEP-15 lands we cut alpha1,
>> 2a. The d
>
> 2. When CEP-15 lands we cut alpha1,
> 2a. The deadline is first week of October, anything not yet in
> cassandra-5.0 is not in 5.0,
> 2b. We expect a minimum two months of testing and beta+rc releases
> to get to GA.
>
> To clarify, is the intent here to say "The deadline for cutoff is
> 2. When CEP-15 lands we cut alpha1,
> 2a. The deadline is first week of October, anything not yet in
> cassandra-5.0 is not in 5.0,
> 2b. We expect a minimum two months of testing and beta+rc releases
> to get to GA.
To clarify, is the intent here to say "The deadline for cutoff is 1st we
>
>> We have a lot of significant features that have or will land soon and our
>> experience suggests that those merges usually bring their set of
>> instabilities. The goal of the proposal was to make sure that we get rid of
>> them before TCM and Accord land to allow us to more easily identify
>
> I'd be happier with something concrete like the following expected release
> flow:
>
> 1) We freeze a branch
> 2) To hit RC, we need green circle + no regression on ASF (or green ASF in
> the future when stable)
> 3) We need N weeks in this frozen state for people to test it out
> 4) Once we ha
> in practice we wait and receive bug reports from downstream testing efforts.
> Such testing isn't necessarily possible pre-commit, e.g. third-party and not
> feasible to continuously run, nor appropriate to upstream/open-source.
>
> We want GA releases to be production ready for any cluster at
> We have a lot of significant features that have or will land soon and our
> experience suggests that those merges usually bring their set of
> instabilities. The goal of the proposal was to make sure that we get rid of
> them before TCM and Accord land to allow us to more easily identify the
> ro
That was my understanding as well.On Mar 30, 2023, at 11:21 AM, Josh McKenzie wrote:So to confirm, let's make sure we all agree on the definition of "stabilize".Using the definition as "green run of all tests on circleci, no regressions on ASF CI" that we used to get 4.1 out the door, and combine
So to confirm, let's make sure we all agree on the definition of "stabilize".
Using the definition as "green run of all tests on circleci, no regressions on
ASF CI" that we used to get 4.1 out the door, and combined with the metric of
"feature branches don't merge until their CI is green on at l
>
> but otherwise I don't recall anything that we could take as an indicator
> that a next release would take a comparable amount of time to 4.1?
Do we have any indicator that proves that it will take less time? We never
managed to do a release in 2 or 3 months so far. Until we have actually
prov
Not so fast...
There's certainly value in spending that time stabilizing the already done
features. It's valuable triaging information to say this used to work
before CEP-21 and only broke after it.
That said, having a very long freeze of trunk, or alternatively having a
very long lived 5.0 branc
> We had far less features in 4.1 and it took us 6 months to release.
Definitely don't want to derail discussion but I could use some clarity. My
current understanding is that the majority of our delay on 4.1 stabilization
was due to ASF CI not being stable and switching to also accepting a
comb
> That does not mean that the code should not be stabilized before the
release. We had far less features in 4.1 and it took us 6 months to
release. Accepting more features until August will probably result in
extending the time needed to stabilize the release.
I think what I'm trying to get at is
>
> SAI, Accord, UCS, and DDM are all features that can be pretty safely
> disabled/not used, and unlike w/ CEP-21, we *should* be able to de-risk
> those things much more easily before they merge.
That does not mean that the code should not be stabilized before the
release. We had far less featu
> I worry about the labor involved with having very large work like this
target a frozen branch and then also needing to pull it up to trunk. That
doesn't sound fun.
> I for one do not like to have release branches cut months before their
expected release.
> CEP-15 is mostly “net new stuff” and n
>
> I’m not sure what freezing early for “extra QA time” really buys us?
Tries, SAI, UCS, extended TTLs, Java 17, Dynamic Data Masking... all those
changes potentially introduce their set of issues/flakiness or other
problems. The freeze will allow us to find those early and facilitate the
integr
Given the fundamental change to how cluster operations work coming from CEP-21,
I’m not sure what freezing early for “extra QA time” really buys us? I
wouldn’t trust any multi-node QA done pre commit.
What “stabilizing” do we expect to be doing during this time? How much of it
do we just have
> 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
On Tue, 7 Mar 2023 at 11:20, Sam Tunnicliffe wrote:
> Currently, we anticipate CEP-21 being in a mergeable state around late
> July/August.
>
For me this is a more important reason to delay the branch date than
CEP-15, it being such a foundational change. Also, this is the first
feedback we've
to
>>> 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
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
Don’t need to revert it so long as the feature they are for is not enabled by
default. Or, if it’s a bit away from being useful enough to even test - mad
hard-disabled without a way to enable.
> On 1 Mar 2023, at 16:34, Henrik Ingo wrote:
>
> already merged 3 patches, but still has 2 to go? Ca
I am cool with defining target release date and working backwards from there.
If we do want to go this route, I think we do need to answer why 4.1 cut ->
release took so much time, and if people could start validation “before” we
branch? If we know trunk is stable today then we could release t
We have been talking a lot about the branch cutting date, but I agree with Benedict here, I think we should actually be talking about the expected release date. If we truly believe that we can release within 1-2 months of cutting the branch, and many people I have talked to think that is possible,
Hi
Those are great questions Mick. It's good to recognize this discussion
impacts a broad range of contributors and users, and not all of them might
be aware of the discussion in the first place.
More generally I would say that your questions brought to mind two
fundamental principles with a "tra
In the interest of broadening perspectives, thoughts here from two angles:
community engagement and marketing. We will be discussing what’s coming in
Cassandra 5.0 at Cassandra Forward in 2 weeks. This is meant to build
excitement for the next version so having technology for folks to get thei
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 reasoning proposed I can see why folk would expect this
would happen for the next release. I don’t think there was a stro
>
> My thoughts don't touch on CEPs inflight.
>
For the sake of broadening the discussion, additional questions I think
worthwhile to raise are…
1. What third parties, or other initiatives, are invested and/or working
against the May deadline? and what are their views on changing it?
1a. If w
Regarding “We should focus on why it took 6 months to go from 4.1 first alpha to GA and what happened inside that time window.” —Speaking solely from my perspective, the single biggest time draw was tracking down and resolving https://issues.apache.org/jira/browse/CASSANDRA-18110.One of the strateg
I agree, we shouldn’t be branching annually, we should be releasing annually - and we shouldn’t assume that will take six months. We should be aiming for 1-2mo and so long as our trajectory towards that is good, I don’t think there’s anything to worry about (and we’ll get our first comparative data
By “not to have to delay again” I mean GA, not the agreement for when to
branch and start feature freeze. Just to be clear as I realized I might be
misunderstood :-)
On Tue, 28 Feb 2023 at 10:47, Ekaterina Dimitrova
wrote:
> I agree that November-May falls too short so +1 on postponing the day o
I agree that November-May falls too short so +1 on postponing the day on my
end
Now I think Mick brought excellent point - let’s get into separate
discussion about the root cause of releasing 4.1 only in December and see
what we need to change/improve on so we do not get into future delays and
we
>
> We forked the 4.0 and 4.1 branches beginning of May. Unfortunately, for
> 4.1 we were only able to release GA in December which impacted how much
> time we could spend focussing on the next release and the progress that we
> could do. By consequence, I am wondering if it makes sense for us to b
I think it makes sense to plan on cutting the branch later given when 4.1
actually released. I would suggest either August or September as a good time to
cut the branch, at the end of the summer.
-Jeremiah
> On Feb 28, 2023, at 7:42 AM, Benjamin Lerer wrote:
>
>
> Hi,
>
> We forked the 4.0
Hi,
We forked the 4.0 and 4.1 branches beginning of May. Unfortunately, for 4.1
we were only able to release GA in December which impacted how much time we
could spend focussing on the next release and the progress that we could
do. By consequence, I am wondering if it makes sense for us to branch
75 matches
Mail list logo
