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