+1


> On 19 Nov 2025, at 16:51, Josh McKenzie <[email protected]> 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
> 
> 

Reply via email to