+1 On Thu, Nov 27, 2025 at 6:34 PM Jaydeep Chovatia <[email protected]> wrote:
> +1 > > > On Nov 27, 2025, at 4:52 PM, Michael Shuler <[email protected]> > wrote: > > > > +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 > > >
