> +1 and as I understand it, cut a 6.0-alpha ASAP? I am running JDK21 support CI on trunk in ASF pre-ci as we speak my good man.
But yeah - we'll want to open a thread to discuss where things are on trunk right now and if there's any blockers or things we need to iron out before branching. On Wed, Nov 19, 2025, at 12:19 PM, David Capwell wrote: > +1 > >> On Nov 19, 2025, at 9:01 AM, Bernardo Botella <[email protected]> >> wrote: >> >> +1 (non-PMC) >> >>> On Nov 19, 2025, at 8:22 AM, Paulo Motta <[email protected]> wrote: >>> >>> +1 >>> >>> On Wed, Nov 19, 2025 at 11:11 AM Štefan Miklošovič <[email protected]> >>> wrote: >>>> +1 >>>> >>>> On Wed, Nov 19, 2025 at 4:52 PM 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 >>>> > >>>> >
