when beta1 is cut the new GA branch is also cut. So in this case the cassandra-6.0 branch would be made. So 6.0 would stabilize through betaX, rcX, and then GA releases on the cassandra-6.0 branch while trunk continues to take new features for 7.0.
On Wed, Nov 19, 2025 at 4:28 PM Dmitry Konstantinov <[email protected]> wrote: > It is pretty base case actually: a feature is developed and ready to merge > in trunk, do we have any feature freeze periods in our lifecycle when it is > not not possible... > Originally I thought that we planned to use a branch for stabilization to > avoid trunk feature freezing but later I realized that it is not a part of > the proposal. > > On Wed, 19 Nov 2025 at 21:17, Josh McKenzie <[email protected]> wrote: > >> As written that we're voting on, we'd merge the feature to trunk whenever >> it's ready (shared definition of "ready" TBD) and the next alpha will have >> that new feature available. Or, if it's right at the end of the cycle, that >> new feature would first show up in a release in -beta1. >> >> When you say "how we manage the case", can you elaborate on what the >> challenges or tension is that you're thinking of? I feel like there's >> something you're seeing as a challenge that I'm missing and want to make >> sure we don't miss it. >> >> On Wed, Nov 19, 2025, at 1:53 PM, Dmitry Konstantinov wrote: >> >> I am trying to understand how we manage the case when a feature is ready >> to merge into trunk but we have a set of alpha versions released.. >> >> >> > > -- > Dmitry Konstantinov >
