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 >
