Works for me
> On Nov 16, 2025, at 4:05 PM, Jeremiah Jordan <[email protected]> wrote:
>
> The main text sounds good to me. I’m not quite sure what you are trying to
> say in the 6.0 part at the end.
> Are you saying that we might cut the 6.0.0-beta1 and 6.0-dev branch any time
> between now and April if people feel it is ready?
> If so I think that’s probably fine. But I think it needs to be reworded to
> make that clear.
>
> Thanks for working through this!
>
> -Jeremiah
>
> On Sun, Nov 16, 2025 at 9:46 AM Josh McKenzie <[email protected]
> <mailto:[email protected]>> wrote:
>> I think I'm seeing consensus.
>>
>> So here's my first cut at a text I'd like to formally propose based on our
>> conversation from this thread; please let me know if you have a concern from
>> this thread I've missed or if I misunderstood or misread a consensus point.
>> We will need an exception to the following "April to April" cadence for 6.0
>> as we transition from one schedule to another; this is noted at the end of
>> the draft.
>>
>> We'll retain the "alpha" label as agreed rather than "snapshot" and update
>> the Release Lifecycle doc to reflect this.
>>
>> ---
>> 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:
>> For the 6.0 .MAJOR, we will target a branch and release at any date up to
>> April 1st 2026 at the latest based on the community consensus to accommodate
>> the longer development window and volume of work in trunk as we transition
>> from the prior release cadence.
>> ---
>> As always - I appreciate everyone's time and input on this.
>>
>> On Fri, Nov 14, 2025, at 7:33 PM, Jaydeep Chovatia wrote:
>>> +1 to the proposal.
>>>
>>> Jaydeep
>>>
>>> On Fri, Nov 14, 2025 at 2:49 PM Caleb Rackliffe <[email protected]
>>> <mailto:[email protected]>> wrote:
>>> +1 to the proposal
>>>
>>> > We reserve the right to release more frequently than this if we decide to
>>> > MAJOR.MINOR? Would keep oldest GA for a predictable length with support
>>> > model but introduce a new branch into our merge-path which is extra merge
>>> > and CI toil.
>>> > Or new MAJOR and we drop oldest supported? If we cut alphas (see below),
>>> > the pressure for out-of-cycle releases to make features available may be
>>> > mitigated.
>>>
>>> If we really want to do this, it feels reasonable to say it should be
>>> something important enough to force a new MAJOR, drop the oldest supported
>>> major, and "reset" the "alpha clock" back to 1. Otherwise, making it into
>>> the next scheduled alpha and then the following MAJOR on a 12-month
>>> boundary should be fine. The nightmare scenario for that, though, is when
>>> we want to do it in, let's say...February, while the Jan 1 MAJOR is in
>>> beta. Maybe it's better to just avoid it.
>>>
>>> On Thu, Nov 13, 2025 at 2:30 PM Josh McKenzie <[email protected]
>>> <mailto:[email protected]>> wrote:
>>>
>>>> What I mean is if we decide the train leaves the station on December 1,
>>>> how do we choose the features on the train?
>>> Features merged to trunk should be in one of the following 3 states:
>>> alpha: Not exposed to users if they don't yet work (available via .yaml
>>> config maybe, etc)
>>> beta: Exposed but flagged as experimental and off by default
>>> ga: Exposed and available by default (barring any guardrails, etc)
>>> So whatever features are committed and beta before that date are in the
>>> release and available at varying levels of ease to our users. No need to
>>> decide what goes into a release since, worst-case, you merge a ga feature
>>> to trunk 1 day after we froze and it's available via the next alpha in 3
>>> months.
>>>
>>> I'm using alpha / beta / GA above in a somewhat new way for us that
>>> reflects what we've actually been doing. I think using the same
>>> alpha/beta/GA hierarchy for features as we use for releases would help
>>> provide consistency and symmetry for user expectations, but that's another
>>> topic I plan to bring up after we get alignment here.
>>>
>>> On Thu, Nov 13, 2025, at 2:59 PM, Brandon Williams wrote:
>>>> On Thu, Nov 13, 2025 at 1:55 PM Patrick McFadin <[email protected]
>>>> <mailto:[email protected]>> wrote:
>>>> >
>>>> > What I mean is if we decide the train leaves the station on December 1,
>>>> > how do we choose the features on the train?
>>>>
>>>> They are committed before the train leaves, or they have to wait for
>>>> the next one.
>>>>
>>>> Kind Regards,
>>>> Brandon
>>>>
>>>
>>
