+1 On Wed, Nov 19, 2025 at 12:25 PM Josh McKenzie <[email protected]> wrote:
> +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 > > > > > > >
