+1
On 11/19/25 8:51 AM, Josh McKenzie wrote:
I propose we vote on adding the below text to our wiki (https://
cwiki.apache.org/confluence/display/cassandra/ <https://
cwiki.apache.org/confluence/display/cassandra/>) and start executing on
this release cycle.
Discuss thread: https://lists.apache.org/thread/
y3fyv596h83vwmpc85x4vpq78p1r12l4 <https://lists.apache.org/thread/
y3fyv596h83vwmpc85x4vpq78p1r12l4>
[VOTING STRUCTURE]
Current roll call is 27 (see: https://cwiki.apache.org/confluence/
display/CASSANDRA/Cassandra+Project+Governance <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 <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 <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
