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