+1 (nb)
On Sat, 22 Nov 2025 at 23:04, Ekaterina Dimitrova <[email protected]> wrote: > > +1 > > На пт, 21.11.2025 г. в 12:45 Josh McKenzie <[email protected]> написа: >> >> 11 +1 from PMC. >> 3 to go. >> >> On Thu, Nov 20, 2025, at 8:08 AM, Brandon Williams wrote: >> >> +1 >> >> Kind Regards, >> Brandon >> >> On Wed, Nov 19, 2025 at 9:52 AM 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 >> > >> > >>
