>
>> 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 root
>> causes of problems.
>
>
> Agree with Benjamin that testing in phases, i.e. separate periods of time,
> has positives that we can take advantage of.
>
Where did we land on this?
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 Summit,
- freeing up folk to start QA (that makes sense to start) immediately
;I'm going to suggest the following…
1. Once all CEPs except CEP-21 and CEP-15 land we branch cassandra-5.0,
1a. QA starts on cassandra-5.0,
1b. CEP-21 and CEP-15 are waivered to land in cassandra-5.0, and
forward-merge to trunk,
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.
Additional notes,
1) "Once all CEPs" includes jdk17 and extending TTL tickets.
1) We ask folk to be considerate of what they commit in trunk wrt to
the inbound CEP-21.
1a) There's an understanding of what needs to be re-tested after CEP-21.
2) The initial release may be beta1, we make that call at that time.
2a) features not complete can still be in 5.0 as experimental and not
enabled by default.
2b) If CEP-15 lands Aug/Sept, then the earliest possible GA release
date is in October.
I feel this proposal will give us evidence and help put us back on
track for a release train model with a shorter QA2GA period, and
aiming for a 5.1 release a bit earlier in the 2024 year (e.g. Q3).
If we agree on this proposal I will update our downloads page (ref
German's thread).
