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
