Awesome visualization - thanks! I think a simple way to hopefully calibrate why I wasn't sure on your question: We freeze GA branches once they're cut (bugfixes lazy consensus, improvements / new features discussed on ML); we do not freeze trunk.
We did an extended freeze on trunk once in the past in an effort to stabilize the project broadly. There were pros and cons to that approach, but as of right now I know myself and a number of PMC members are a hard -1 on freezing trunk from new features or improvements in the future. Also - never say never and all that; all this stuff is up for discussion. The most important thing in my mind is why we felt the need to do that in the past - I *strongly believe* we have some work to do when it comes to "how do we prevent trunk getting to a place where a GA branch cut from it takes an unacceptable amount of time to stabilize". That's another topic (though it does intersect with our release cadence as a concept quite a bit). :) On Wed, Nov 19, 2025, at 6:27 PM, David Capwell wrote: > Awesome! Thats a very useful visualization! > >> On Nov 19, 2025, at 3:15 PM, Dmitry Konstantinov <[email protected]> wrote: >> >> Corrected: >> <image.png> >> >> >> On Wed, 19 Nov 2025 at 23:11, Dmitry Konstantinov <[email protected]> wrote: >>> I see, I've tried to summaize what I've got in the following diagram: >>> >>> <image.png> >>> >>> On Wed, 19 Nov 2025 at 22:47, Jeremiah Jordan <[email protected]> wrote: >>>> 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 >>> >>> >>> -- >>> Dmitry Konstantinov >> >> >> -- >> Dmitry Konstantinov
