cwiki article with the voted upon text published here: https://cwiki.apache.org/confluence/display/CASSANDRA/Release+Cadence+and+Alpha+Releases
This is nested under "Project Governance and Operations" on the home page of the wiki here: https://cwiki.apache.org/confluence/display/CASSANDRA/Home On Mon, Dec 1, 2025, at 12:57 PM, Josh McKenzie wrote: > Let's go ahead and close voting. Clear consensus and vote passes; will send > out results email in a bit. > > On Sun, Nov 30, 2025, at 10:21 PM, Joseph Lynch wrote: >> +1 >> >> On Sun, Nov 30, 2025 at 8:08 PM Jyothsna Konisa <[email protected]> >> wrote: >>> +1 >>> >>> On Sun, Nov 30, 2025 at 4:20 PM Isaac Reath <[email protected]> wrote: >>>> +1 >>>> >>>> On Sun, Nov 30, 2025 at 4:23 PM Francisco Guerrero <[email protected]> >>>> wrote: >>>>> +1 >>>>> >>>>> On 2025/11/19 15:51:15 Josh McKenzie wrote: >>>>> > I propose we vote on adding the below text to our wiki >>>>> > (https://cwiki.apache.org/confluence/display/cassandra/) and start >>>>> > executing on this release cycle. >>>>> > >>>>> > Discuss thread: >>>>> > https://lists.apache.org/thread/y3fyv596h83vwmpc85x4vpq78p1r12l4 >>>>> > >>>>> > [VOTING STRUCTURE] >>>>> > Current roll call is 27 (see: >>>>> > https://cwiki.apache.org/confluence/display/CASSANDRA/Cassandra+Project+Governance) >>>>> > >>>>> > Procedure for this vote: this is a process change. See governance doc >>>>> > here: >>>>> > https://cwiki.apache.org/confluence/display/CASSANDRA/Cassandra+Project+Governance >>>>> > > Discussion / binding votes on project structure and governance >>>>> > > changes (adopting subprojects, how we vote and govern, etc). (super >>>>> > > majority) >>>>> > >>>>> > > A majority of the electorate at the time a vote is called is the >>>>> > > low-watermark for votes in favour necessary to pass a motion; that >>>>> > > is, both types of majority votes (simple and super-majority) require >>>>> > > this 50% of last roll call participation. >>>>> > >>>>> > > *Super majority voting:* 66% of votes must be in favor to pass. >>>>> > > Requires 50% participation of roll call. >>>>> > So 14 binding participants required, 10 of which must be in favor. >>>>> > >>>>> > I'll plan on leaving the vote open through at least Dec 1 given the >>>>> > upcoming holiday week; if we hit the required low water mark for it and >>>>> > have very clear consensus at that point I'll poll to close it early so >>>>> > we can get this codified and move on to other discussions. >>>>> > >>>>> > Text to vote on as follows: >>>>> > --- >>>>> > *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:* >>>>> > • 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 >>>>> > >
