Hi,
I was going to release it but my local setup is incompatible atm. I
think it's better Stefan does it bc of CASSANDRA-18118 i.e.
Regards
On 17/4/23 17:49, Brandon Williams wrote:
I think Berenguer was going to release it, but needed CASSANDRA-18249
which didn't pan out. Berenguer, are yo
> 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
I concur with Scott here. LTS and extended support is precisely what
vendors are in a good position to offer. And in practice such support is
always available, also today, since a vendor will always agree to support
any old version as long as a price is agreed for the custom arrangement.
If I thin
>
> 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
Sorry for the delay on the summary of build lead for those two weeks.
We had quite a few new failures during the 2 week period:
CASSANDRA-18427
Test failure: pdtest:
dtest-novnode.ttl_test.TestDistributedTTL.test_ttl_is_respected_on_delayed_replication
CASSANDRA-18426
Test failure: pdtest:
d
> 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
I think Berenguer was going to release it, but needed CASSANDRA-18249
which didn't pan out. Berenguer, are you able to release or should
Stefan handle it? I don't think there is anything to wait for;
there's already plenty important things to release.
Kind Regards,
Brandon
On Mon, Apr 17, 2023
What about releasing 3.11.15? 3.11.14 was released 6 months ago. Is there
anything people want to see in 3.11.15 so we should wait a while?
I give it some time and if I see no response I consider it as I can just cut it.
From: Miklosovic, Stefan
Sent: Th
The pull request [1] is a proposed fix for CASSANDRA-17773. I am looking
for comments and a decision as to whether to move forward or not with this
change.
The goal is to remove much of the boiler-plate code from scripts without
changing their functionality or arguments and to add the ability to
>
> 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
20 matches
Mail list logo
