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 >> >
