Let me explain my understanding by using an example: backports, such as *Backport#1: CEP-37* and *Backport#2: JDK 21* to 4.1.
1. To simplify the example (just for the sake of this discussion only), let me name our existing 4.1 branch to *4.1-bugfixes*, which would continue to receive only bugfixes that we have already been doing 2. Create a new branch, say, *4.1-bugfixes-backport* (parent: 4.1- *bugfixes*) >1.) Should we have a mechanism to backport CEP-37, Java 21, and things like them that do not introduce messaging or on-disk version changes? (Yes/No) Yes, and it should go through a rigorous community vote. Backporting a feature should have an extremely high bar. >2.) Where should those backports happen? (An existing major version branch/a new branch/it depends on the feature) Backport#1 and Backport#2 would go to *4.1-bugfixes-backport**. * Later, if a person P1 fixes some bug B1 on 5.0/trunk, and if that bug needs to be ported to *4.1-bugfixes*, then that person P1 also needs to port the bug to *4.1-bugfixes-backport* So at this point, this is how both the branches would look: 4.1-*bugfixes* - Contains B1 4.1-*bugfixes-backport* - Contains B1 + Backport#1 + Backport#2 Jaydeep On Mon, Oct 13, 2025 at 2:32 PM Caleb Rackliffe <[email protected]> wrote: > Forgot... > > 4.) If a new branch is introduced, what should be the fate of > cassandra-4.0? (make unsupported when the new branch releases/keep until > 6.0 releases) > > On Mon, Oct 13, 2025 at 4:23 PM Mick <[email protected]> wrote: > >> >> >> > On 13 Oct 2025, at 20:13, Štefan Miklošovič <[email protected]> >> wrote: >> > >> > What about this: do a proper 5.1 branch with everything (pipelines, >> release ...) but put there only Java 21 support and CEP-37? >> > >> > Release-wise, the appetite is there (Josh, Bernardo). We would keep 5.0 >> intact, 5.1 would be a branch we try this new model in, learn the lessons >> from it. When we support Java 21 and CEP-37 as only two changes and nothing >> else, it will already address Java 21 / unsupported Java 17 concerns and it >> would bring a lot of relief to people trying to transition to 6.0 >> eventually and they would have some time to prepare for that. Then, in 6.0, >> TCM / Accord would be production ready waiting for them to migrate to, >> while they would already be on Java 21 + repairs. >> >> >> Yes Stefan, this has my vote. This is an approach that is known and >> tangible to us, and bounded. >> >> I do believe it will help both user and downstreamers move closer to >> trunk. This is a good thing, and the burden it introduces: forward merging >> and upgrade paths; we can manage (and importantly it's those more active on >> older branches that are now agreeing to this). >> >> We're also acknowledging that this is attracting new contributors, which >> may be a net-win for us. >> >>
