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