+1 and as I understand it, cut a 6.0-alpha ASAP?

On Wed, Nov 19, 2025 at 7:58 AM Jon Haddad <[email protected]> wrote:

> +1
>
> On Wed, Nov 19, 2025 at 7:54 AM Josh McKenzie <[email protected]>
> wrote:
>
>> +1
>>
>> On Wed, Nov 19, 2025, at 10:51 AM, Josh McKenzie 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
>>
>>
>>

Reply via email to