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
