yes, I've re-read the VOTE proposal and noticed: "For alpha releases, it's built and released from a tag. No new branches." Do we have a freeze process description somewhere? 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..
On Wed, 19 Nov 2025 at 18:50, Ekaterina Dimitrova <[email protected]> wrote: > I think yes, Caleb. There was an early mention we should add to our > procedure - cut a branch on beta release. > > On Wed, 19 Nov 2025 at 13:42, Caleb Rackliffe <[email protected]> > wrote: > >> I think (and hope) the alphas would be cut from trunk...? >> >> On Wed, Nov 19, 2025 at 12:32 PM Dmitry Konstantinov <[email protected]> >> wrote: >> >>> sorry for the late message, it is not a concern just a clarification. >>> So, am I right that we will have one more branch to support (merge bug >>> fixes) and correspondent CI job (so 5 in total), like 4.0, 4.1, 5.0, 6.0 >>> (with alphas) and trunk? >>> >>> Regards, >>> Dmitry >>> >>> On Mon, 17 Nov 2025 at 17:47, Josh McKenzie <[email protected]> >>> wrote: >>> >>>> Are you saying that we might cut the 6.0.0-beta1 and 6.0-dev branch any >>>> time between now and April if people feel it is ready? >>>> If so I think that’s probably fine. But I think it needs to be reworded >>>> to make that clear. >>>> >>>> That's what I was trying for. Poorly. :) >>>> >>>> Take 2: >>>> --- >>>> *Transition:* >>>> >>>> - Rather than waiting until April of 2026 for 6.0 as per the new >>>> schedule, since it's been over a year since 5.0 released we will plan to >>>> release 6.0 any time between now and April of 2026 at the latest. The >>>> train >>>> may leave early but worst-case it'll go out on time. >>>> - We will plan on cutting 7.0 in April of 2027 >>>> >>>> --- >>>> My thinking: even if we were to cut a 6.0 branch tomorrow, we'd be >>>> looking ~2 years of code changes between 5.0 and 6.0 branches (I think it >>>> was around Dec '23 branch for 5.0 created? And then it took to Sep '24 to >>>> stabilize). So if we have somewhere around 1.5-2 years worth of features in >>>> the 6.0 line, then between Nov '25 and April '26 we'd accumulate ~1.5 years >>>> worth of features, then get to the final targeted 1 year worth of features >>>> per GA. >>>> >>>> >>>> On Mon, Nov 17, 2025, at 12:17 PM, David Capwell wrote: >>>> >>>> Works for me >>>> >>>> On Nov 16, 2025, at 4:05 PM, Jeremiah Jordan <[email protected]> >>>> wrote: >>>> >>>> The main text sounds good to me. I’m not quite sure what you are trying >>>> to say in the 6.0 part at the end. >>>> Are you saying that we might cut the 6.0.0-beta1 and 6.0-dev branch any >>>> time between now and April if people feel it is ready? >>>> If so I think that’s probably fine. But I think it needs to be reworded >>>> to make that clear. >>>> >>>> Thanks for working through this! >>>> >>>> -Jeremiah >>>> >>>> On Sun, Nov 16, 2025 at 9:46 AM Josh McKenzie <[email protected]> >>>> wrote: >>>> >>>> >>>> I think I'm seeing consensus. >>>> >>>> So here's my first cut at a text I'd like to formally propose based on >>>> our conversation from this thread; please let me know if you have a concern >>>> from this thread I've missed or if I misunderstood or misread a consensus >>>> point. We will need an exception to the following "April to April" cadence >>>> for 6.0 as we transition from one schedule to another; this is noted at the >>>> end of the draft. >>>> >>>> We'll retain the "alpha" label as agreed rather than "snapshot" and >>>> update the Release Lifecycle doc to reflect this. >>>> >>>> --- >>>> *Summary:* >>>> We target a yearly MAJOR release cadence, cutting a new release branch >>>> on April 1st that we then stabilize. Our yearly branching cadence will run >>>> from April to April - this avoids holiday crunch on feature finalization. >>>> We will release alphas at the beginning of all other quarters (i.e. July, >>>> October, January). >>>> >>>> Alphas give downstream users a stable snapshot for qualification and >>>> internal testing that is much nearer the upcoming GA. >>>> >>>> All dates are aspirational - we’re an open‑source project that relies >>>> on volunteers, so flexibility is expected. >>>> >>>> See our Release Lifecycle wiki for details on the definitions of alpha, >>>> beta, and rc: >>>> https://cwiki.apache.org/confluence/display/CASSANDRA/Release+Lifecycle >>>> >>>> *Yearly MAJOR release cadence:* >>>> >>>> - A release branch from trunk is created April 1st. >>>> - A MAJOR.0.0-beta1 release is packaged from that branch and made >>>> available shortly after freeze date. >>>> - Only features that have reached -beta / experimental status will >>>> be available in the next MAJOR. >>>> - We cut new -betaN releases as needed (see Release Lifecycle >>>> documentation). There is no fixed calendar lifecycle for beta >>>> progression. >>>> - RCs and the final GA follow the normal release lifecycle process >>>> (beta -> rc -> ga) and are cut based on criteria in our Release >>>> Lifecycle. >>>> - A new -beta1 for the next MAJOR is always cut the next April 1 >>>> after the prior -beta1 independent of when the prior .MAJOR reaches GA. >>>> - Stabilization of adjacent .MAJOR lines and promotion from beta to >>>> rc to ga are independent. >>>> >>>> *Alpha release cadence:* >>>> >>>> - At the start of each non-April quarter we cut an alpha-N release. >>>> - Target dates will be July 1st (alpha-1), October 1st (alpha-2), >>>> Jan 1st (alpha-3). >>>> - For alpha releases, it's built and released from a tag. No new >>>> branches. >>>> - Alphas receive no support; security fixes or bug‑fix backports >>>> are applied only to trunk and GA branches. >>>> - Alphas go through the standard Apache release process; they are >>>> voted on, artifacts prepared, and notification is sent on the dev@, >>>> user@, and ASF slack channels but not published on the download >>>> page. >>>> >>>> *Subprojects:* >>>> >>>> - Sub‑projects are encouraged but not required to follow the same >>>> April → July → Oct → Jan cadence; they may skip a quarter if there is >>>> nothing releasable after a brief dev@ discussion. >>>> >>>> *Transition:* >>>> >>>> - For the 6.0 .MAJOR, we will target a branch and release at any >>>> date up to April 1st 2026 at the latest based on the community >>>> consensus to >>>> accommodate the longer development window and volume of work in trunk >>>> as we >>>> transition from the prior release cadence. >>>> >>>> --- >>>> As always - I appreciate everyone's time and input on this. >>>> >>>> On Fri, Nov 14, 2025, at 7:33 PM, Jaydeep Chovatia wrote: >>>> >>>> +1 to the proposal. >>>> >>>> Jaydeep >>>> >>>> On Fri, Nov 14, 2025 at 2:49 PM Caleb Rackliffe < >>>> [email protected]> wrote: >>>> >>>> +1 to the proposal >>>> >>>> > *We reserve the right to release more frequently than this if we >>>> decide to* >>>> > MAJOR.MINOR? Would keep oldest GA for a predictable length with >>>> support model but introduce a new branch into our merge-path which is extra >>>> merge and CI toil. >>>> > Or new MAJOR and we drop oldest supported? If we cut alphas (see >>>> below), the pressure for out-of-cycle releases to make features available >>>> may be mitigated. >>>> >>>> If we really want to do this, it feels reasonable to say it should be >>>> something important enough to force a new MAJOR, drop the oldest >>>> supported major, and "reset" the "alpha clock" back to 1. Otherwise, making >>>> it into the next scheduled alpha and then the following MAJOR on a 12-month >>>> boundary should be fine. The nightmare scenario for that, though, is when >>>> we want to do it in, let's say...February, while the Jan 1 MAJOR is in >>>> beta. Maybe it's better to just avoid it. >>>> >>>> On Thu, Nov 13, 2025 at 2:30 PM Josh McKenzie <[email protected]> >>>> wrote: >>>> >>>> >>>> What I mean is if we decide the train leaves the station on December 1, >>>> how do we choose the features on the train? >>>> >>>> Features merged to trunk should be in one of the following 3 states: >>>> >>>> 1. alpha: Not exposed to users if they don't yet work (available >>>> via .yaml config maybe, etc) >>>> 2. beta: Exposed but flagged as experimental and off by default >>>> 3. ga: Exposed and available by default (barring any guardrails, >>>> etc) >>>> >>>> So whatever features are committed and beta before that date are in the >>>> release and available at varying levels of ease to our users. No need to >>>> decide what goes into a release since, worst-case, you merge a ga feature >>>> to trunk 1 day after we froze and it's available via the next alpha in 3 >>>> months. >>>> >>>> I'm using alpha / beta / GA above in a somewhat new way for us that >>>> reflects what we've *actually* been doing. I think using the same >>>> alpha/beta/GA hierarchy for features as we use for releases would help >>>> provide consistency and symmetry for user expectations, but that's another >>>> topic I plan to bring up after we get alignment here. >>>> >>>> On Thu, Nov 13, 2025, at 2:59 PM, Brandon Williams wrote: >>>> >>>> On Thu, Nov 13, 2025 at 1:55 PM Patrick McFadin <[email protected]> >>>> wrote: >>>> > >>>> > What I mean is if we decide the train leaves the station on December >>>> 1, how do we choose the features on the train? >>>> >>>> They are committed before the train leaves, or they have to wait for >>>> the next one. >>>> >>>> Kind Regards, >>>> Brandon >>>> >>>> >>>> >>>> >>>> >>> >>> -- >>> Dmitry Konstantinov >>> >> -- Dmitry Konstantinov
