Re: [DISCUSS] Proposal: formalize release cadence and alphas from trunk

[Josh McKenzie]

Awesome visualization - thanks!

I think a simple way to hopefully calibrate why I wasn't sure on your question: 
We freeze GA branches once they're cut (bugfixes lazy consensus, improvements / 
new features discussed on ML); we do not freeze trunk.

We did an extended freeze on trunk once in the past in an effort to stabilize 
the project broadly. There were pros and cons to that approach, but as of right 
now I know myself and a number of PMC members are a hard -1 on freezing trunk 
from new features or improvements in the future. Also - never say never and all 
that; all this stuff is up for discussion.

The most important thing in my mind is why we felt the need to do that in the 
past - I *strongly believe* we have some work to do when it comes to "how do we 
prevent trunk getting to a place where a GA branch cut from it takes an 
unacceptable amount of time to stabilize". That's another topic (though it does 
intersect with our release cadence as a concept quite a bit). :)

On Wed, Nov 19, 2025, at 6:27 PM, David Capwell wrote:
> Awesome!  Thats a very useful visualization!
> 
>> On Nov 19, 2025, at 3:15 PM, Dmitry Konstantinov  wrote:
>> 
>> Corrected:
>> 
>> 
>> 
>> On Wed, 19 Nov 2025 at 23:11, Dmitry Konstantinov  wrote:
>>> I see, I've tried to summaize what I've got in the following diagram:
>>> 
>>> 
>>> 
>>> On Wed, 19 Nov 2025 at 22:47, Jeremiah Jordan  wrote:
 when beta1 is cut the new GA branch is also cut. So in this case the 
 cassandra-6.0 branch would be made. So 6.0 would stabilize through betaX, 
 rcX, and then GA releases on the cassandra-6.0 branch while trunk 
 continues to take new features for 7.0.
 
 
 On Wed, Nov 19, 2025 at 4:28 PM Dmitry Konstantinov  
 wrote:
> It is pretty base case actually: a feature is developed and ready to 
> merge in trunk, do we have any feature freeze periods in our lifecycle 
> when it is not not possible...
> Originally I thought that we planned to use a branch for stabilization to 
> avoid trunk feature freezing but later I realized that it is not a part 
> of the proposal.
> 
> On Wed, 19 Nov 2025 at 21:17, Josh McKenzie  wrote:
>> __
>> As written that we're voting on, we'd merge the feature to trunk 
>> whenever it's ready (shared definition of "ready" TBD) and the next 
>> alpha will have that new feature available. Or, if it's right at the end 
>> of the cycle, that new feature would first show up in a release in 
>> -beta1.
>> 
>> When you say "how we manage the case", can you elaborate on what the 
>> challenges or tension is that you're thinking of? I feel like there's 
>> something you're seeing as a challenge that I'm missing and want to make 
>> sure we don't miss it.
>> 
>> On Wed, Nov 19, 2025, at 1:53 PM, Dmitry Konstantinov wrote:
>>> I am trying to understand how we manage the case when a feature is 
>>> ready to merge into trunk but we have a set of alpha versions released..
>> 
> 
> 
> --
> Dmitry Konstantinov
>>> 
>>> 
>>> --
>>> Dmitry Konstantinov
>> 
>> 
>> --
>> Dmitry Konstantinov

Re: [DISCUSS] Proposal: formalize release cadence and alphas from trunk

[David Capwell]

Awesome!  Thats a very useful visualization!

> On Nov 19, 2025, at 3:15 PM, Dmitry Konstantinov  wrote:
> 
> Corrected:
> 
> 
> 
> On Wed, 19 Nov 2025 at 23:11, Dmitry Konstantinov  > wrote:
>> I see, I've tried to summaize what I've got in the following diagram:
>> 
>> 
>> 
>> On Wed, 19 Nov 2025 at 22:47, Jeremiah Jordan > > wrote:
>>> when beta1 is cut the new GA branch is also cut. So in this case the 
>>> cassandra-6.0 branch would be made. So 6.0 would stabilize through betaX, 
>>> rcX, and then GA releases on the cassandra-6.0 branch while trunk continues 
>>> to take new features for 7.0.
>>> 
>>> 
>>> On Wed, Nov 19, 2025 at 4:28 PM Dmitry Konstantinov >> > wrote:
 It is pretty base case actually: a feature is developed and ready to merge 
 in trunk, do we have any feature freeze periods in our lifecycle when it 
 is not not possible...
 Originally I thought that we planned to use a branch for stabilization to 
 avoid trunk feature freezing but later I realized that it is not a part of 
 the proposal.
 
 On Wed, 19 Nov 2025 at 21:17, Josh McKenzie >>> > wrote:
> As written that we're voting on, we'd merge the feature to trunk whenever 
> it's ready (shared definition of "ready" TBD) and the next alpha will 
> have that new feature available. Or, if it's right at the end of the 
> cycle, that new feature would first show up in a release in -beta1.
> 
> When you say "how we manage the case", can you elaborate on what the 
> challenges or tension is that you're thinking of? I feel like there's 
> something you're seeing as a challenge that I'm missing and want to make 
> sure we don't miss it.
> 
> On Wed, Nov 19, 2025, at 1:53 PM, Dmitry Konstantinov wrote:
>> I am trying to understand how we manage the case when a feature is ready 
>> to merge into trunk but we have a set of alpha versions released..
> 
 
 
 
 --
 Dmitry Konstantinov
>> 
>> 
>> 
>> --
>> Dmitry Konstantinov
> 
> 
> 
> --
> Dmitry Konstantinov

Re: [DISCUSS] Proposal: formalize release cadence and alphas from trunk

[Jeremiah Jordan]

when beta1 is cut the new GA branch is also cut. So in this case the
cassandra-6.0 branch would be made. So 6.0 would stabilize through betaX,
rcX, and then GA releases on the cassandra-6.0 branch while trunk continues
to take new features for 7.0.


On Wed, Nov 19, 2025 at 4:28 PM Dmitry Konstantinov 
wrote:

> It is pretty base case actually: a feature is developed and ready to merge
> in trunk, do we have any feature freeze periods in our lifecycle when it is
> not not possible...
> Originally I thought that we planned to use a branch for stabilization to
> avoid trunk feature freezing but later I realized that it is not a part of
> the proposal.
>
> On Wed, 19 Nov 2025 at 21:17, Josh McKenzie  wrote:
>
>> As written that we're voting on, we'd merge the feature to trunk whenever
>> it's ready (shared definition of "ready" TBD) and the next alpha will have
>> that new feature available. Or, if it's right at the end of the cycle, that
>> new feature would first show up in a release in -beta1.
>>
>> When you say "how we manage the case", can you elaborate on what the
>> challenges or tension is that you're thinking of? I feel like there's
>> something you're seeing as a challenge that I'm missing and want to make
>> sure we don't miss it.
>>
>> On Wed, Nov 19, 2025, at 1:53 PM, Dmitry Konstantinov wrote:
>>
>> I am trying to understand how we manage the case when a feature is ready
>> to merge into trunk but we have a set of alpha versions released..
>>
>>
>>
>
> --
> Dmitry Konstantinov
>

Re: [DISCUSS] Proposal: formalize release cadence and alphas from trunk

[Dmitry Konstantinov]

It is pretty base case actually: a feature is developed and ready to merge
in trunk, do we have any feature freeze periods in our lifecycle when it is
not not possible...
Originally I thought that we planned to use a branch for stabilization to
avoid trunk feature freezing but later I realized that it is not a part of
the proposal.

On Wed, 19 Nov 2025 at 21:17, Josh McKenzie  wrote:

> As written that we're voting on, we'd merge the feature to trunk whenever
> it's ready (shared definition of "ready" TBD) and the next alpha will have
> that new feature available. Or, if it's right at the end of the cycle, that
> new feature would first show up in a release in -beta1.
>
> When you say "how we manage the case", can you elaborate on what the
> challenges or tension is that you're thinking of? I feel like there's
> something you're seeing as a challenge that I'm missing and want to make
> sure we don't miss it.
>
> On Wed, Nov 19, 2025, at 1:53 PM, Dmitry Konstantinov wrote:
>
> I am trying to understand how we manage the case when a feature is ready
> to merge into trunk but we have a set of alpha versions released..
>
>
>

-- 
Dmitry Konstantinov

Re: [DISCUSS] Proposal: formalize release cadence and alphas from trunk

[Josh McKenzie]

As written that we're voting on, we'd merge the feature to trunk whenever it's 
ready (shared definition of "ready" TBD) and the next alpha will have that new 
feature available. Or, if it's right at the end of the cycle, that new feature 
would first show up in a release in -beta1.

When you say "how we manage the case", can you elaborate on what the challenges 
or tension is that you're thinking of? I feel like there's something you're 
seeing as a challenge that I'm missing and want to make sure we don't miss it.

On Wed, Nov 19, 2025, at 1:53 PM, Dmitry Konstantinov wrote:
> I am trying to understand how we manage the case when a feature is ready to 
> merge into trunk but we have a set of alpha versions released..

Re: [DISCUSS] Proposal: formalize release cadence and alphas from trunk

[Dmitry Konstantinov]

yes, I've re-read the VOTE proposal and noticed: "For alpha releases, it's
built and released from a tag. No new branches."
Do we have a freeze process description somewhere? I am trying to
understand how we manage the case when a feature is ready to merge into
trunk but we have a set of alpha versions released..

On Wed, 19 Nov 2025 at 18:50, Ekaterina Dimitrova 
wrote:

> I think yes, Caleb. There was an early mention we should add to our
> procedure - cut a branch on beta release.
>
> On Wed, 19 Nov 2025 at 13:42, Caleb Rackliffe 
> wrote:
>
>> I think (and hope) the alphas would be cut from trunk...?
>>
>> On Wed, Nov 19, 2025 at 12:32 PM Dmitry Konstantinov 
>> wrote:
>>
>>> sorry for the late message, it is not a concern just a clarification.
>>> So, am I right that we will have one more branch to support (merge bug
>>> fixes) and correspondent CI job (so 5 in total), like 4.0, 4.1, 5.0, 6.0
>>> (with alphas) and trunk?
>>>
>>> Regards,
>>> Dmitry
>>>
>>> On Mon, 17 Nov 2025 at 17:47, Josh McKenzie 
>>> wrote:
>>>
 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.

 That's what I was trying for. Poorly. :)

 Take 2:
 ---
 *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

 ---
 My thinking: even if we were to cut a 6.0 branch tomorrow, we'd be
 looking ~2 years of code changes between 5.0 and 6.0 branches (I think it
 was around Dec '23 branch for 5.0 created? And then it took to Sep '24 to
 stabilize). So if we have somewhere around 1.5-2 years worth of features in
 the 6.0 line, then between Nov '25 and April '26 we'd accumulate ~1.5 years
 worth of features, then get to the final targeted 1 year worth of features
 per GA.


 On Mon, Nov 17, 2025, at 12:17 PM, David Capwell wrote:

 Works for me

 On Nov 16, 2025, at 4:05 PM, Jeremiah Jordan 
 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 
 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 th

Re: [DISCUSS] Proposal: formalize release cadence and alphas from trunk

[Ekaterina Dimitrova]

I think yes, Caleb. There was an early mention we should add to our
procedure - cut a branch on beta release.

On Wed, 19 Nov 2025 at 13:42, Caleb Rackliffe 
wrote:

> I think (and hope) the alphas would be cut from trunk...?
>
> On Wed, Nov 19, 2025 at 12:32 PM Dmitry Konstantinov 
> wrote:
>
>> sorry for the late message, it is not a concern just a clarification.
>> So, am I right that we will have one more branch to support (merge bug
>> fixes) and correspondent CI job (so 5 in total), like 4.0, 4.1, 5.0, 6.0
>> (with alphas) and trunk?
>>
>> Regards,
>> Dmitry
>>
>> On Mon, 17 Nov 2025 at 17:47, Josh McKenzie  wrote:
>>
>>> 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.
>>>
>>> That's what I was trying for. Poorly. :)
>>>
>>> Take 2:
>>> ---
>>> *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
>>>
>>> ---
>>> My thinking: even if we were to cut a 6.0 branch tomorrow, we'd be
>>> looking ~2 years of code changes between 5.0 and 6.0 branches (I think it
>>> was around Dec '23 branch for 5.0 created? And then it took to Sep '24 to
>>> stabilize). So if we have somewhere around 1.5-2 years worth of features in
>>> the 6.0 line, then between Nov '25 and April '26 we'd accumulate ~1.5 years
>>> worth of features, then get to the final targeted 1 year worth of features
>>> per GA.
>>>
>>>
>>> On Mon, Nov 17, 2025, at 12:17 PM, David Capwell wrote:
>>>
>>> Works for me
>>>
>>> On Nov 16, 2025, at 4:05 PM, Jeremiah Jordan 
>>> 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 
>>> 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 fro

Re: [DISCUSS] Proposal: formalize release cadence and alphas from trunk

[Caleb Rackliffe]

I think (and hope) the alphas would be cut from trunk...?

On Wed, Nov 19, 2025 at 12:32 PM Dmitry Konstantinov 
wrote:

> sorry for the late message, it is not a concern just a clarification.
> So, am I right that we will have one more branch to support (merge bug
> fixes) and correspondent CI job (so 5 in total), like 4.0, 4.1, 5.0, 6.0
> (with alphas) and trunk?
>
> Regards,
> Dmitry
>
> On Mon, 17 Nov 2025 at 17:47, Josh McKenzie  wrote:
>
>> 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.
>>
>> That's what I was trying for. Poorly. :)
>>
>> Take 2:
>> ---
>> *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
>>
>> ---
>> My thinking: even if we were to cut a 6.0 branch tomorrow, we'd be
>> looking ~2 years of code changes between 5.0 and 6.0 branches (I think it
>> was around Dec '23 branch for 5.0 created? And then it took to Sep '24 to
>> stabilize). So if we have somewhere around 1.5-2 years worth of features in
>> the 6.0 line, then between Nov '25 and April '26 we'd accumulate ~1.5 years
>> worth of features, then get to the final targeted 1 year worth of features
>> per GA.
>>
>>
>> On Mon, Nov 17, 2025, at 12:17 PM, David Capwell wrote:
>>
>> Works for me
>>
>> On Nov 16, 2025, at 4:05 PM, Jeremiah Jordan  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 
>> 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@,
>

Re: [DISCUSS] Proposal: formalize release cadence and alphas from trunk

[Dmitry Konstantinov]

sorry for the late message, it is not a concern just a clarification.
So, am I right that we will have one more branch to support (merge bug
fixes) and correspondent CI job (so 5 in total), like 4.0, 4.1, 5.0, 6.0
(with alphas) and trunk?

Regards,
Dmitry

On Mon, 17 Nov 2025 at 17:47, Josh McKenzie  wrote:

> 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.
>
> That's what I was trying for. Poorly. :)
>
> Take 2:
> ---
> *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
>
> ---
> My thinking: even if we were to cut a 6.0 branch tomorrow, we'd be looking
> ~2 years of code changes between 5.0 and 6.0 branches (I think it was
> around Dec '23 branch for 5.0 created? And then it took to Sep '24 to
> stabilize). So if we have somewhere around 1.5-2 years worth of features in
> the 6.0 line, then between Nov '25 and April '26 we'd accumulate ~1.5 years
> worth of features, then get to the final targeted 1 year worth of features
> per GA.
>
>
> On Mon, Nov 17, 2025, at 12:17 PM, David Capwell wrote:
>
> Works for me
>
> On Nov 16, 2025, at 4:05 PM, Jeremiah Jordan  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 
> 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
>n

Re: [DISCUSS] Proposal: formalize release cadence and alphas from trunk

[Josh McKenzie]

> 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.
That's what I was trying for. Poorly. :)

Take 2:
---
*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
---
My thinking: even if we were to cut a 6.0 branch tomorrow, we'd be looking ~2 
years of code changes between 5.0 and 6.0 branches (I think it was around Dec 
'23 branch for 5.0 created? And then it took to Sep '24 to stabilize). So if we 
have somewhere around 1.5-2 years worth of features in the 6.0 line, then 
between Nov '25 and April '26 we'd accumulate ~1.5 years worth of features, 
then get to the final targeted 1 year worth of features per GA.


On Mon, Nov 17, 2025, at 12:17 PM, David Capwell wrote:
> Works for me
> 
>> On Nov 16, 2025, at 4:05 PM, Jeremiah Jordan  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  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 

Re: [DISCUSS] Proposal: formalize release cadence and alphas from trunk

[David Capwell]

Works for me

> On Nov 16, 2025, at 4:05 PM, Jeremiah Jordan  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  > 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 >> > 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, le

Re: [DISCUSS] Proposal: formalize release cadence and alphas from trunk

[Jeremiah Jordan]

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  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 
> 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 
> wrote:
>
>
> What I mean is if w

Re: [DISCUSS] Proposal: formalize release cadence and alphas from trunk

[Josh McKenzie]

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  
> 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  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:
>>>  1. alpha: Not exposed to users if they don't yet work (available via .yaml 
>>> config maybe, etc)
>>>  2. beta: Exposed but flagged as experimental and off by default
>>>  3. 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 

Re: [DISCUSS] Proposal: formalize release cadence and alphas from trunk

[Jaydeep Chovatia]

+1 to the proposal.

Jaydeep

On Fri, Nov 14, 2025 at 2:49 PM Caleb Rackliffe 
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 
> 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:
>>
>>1. alpha: Not exposed to users if they don't yet work (available via
>>.yaml config maybe, etc)
>>2. beta: Exposed but flagged as experimental and off by default
>>3. 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 
>> 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
>>
>>
>>

Re: [DISCUSS] Proposal: formalize release cadence and alphas from trunk

[Caleb Rackliffe]

+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  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:
>
>1. alpha: Not exposed to users if they don't yet work (available via
>.yaml config maybe, etc)
>2. beta: Exposed but flagged as experimental and off by default
>3. 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 
> 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
>
>
>

Re: [DISCUSS] Proposal: formalize release cadence and alphas from trunk

[Josh McKenzie]

> 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:
 1. alpha: Not exposed to users if they don't yet work (available via .yaml 
config maybe, etc)
 2. beta: Exposed but flagged as experimental and off by default
 3. 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  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
> 

Re: [DISCUSS] Proposal: formalize release cadence and alphas from trunk

[Brandon Williams]

On Thu, Nov 13, 2025 at 1:55 PM Patrick McFadin  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

Re: [DISCUSS] Proposal: formalize release cadence and alphas from trunk

[Patrick McFadin]

What I mean is if we decide the train leaves the station on December 1, how
do we choose the features on the train? This has been a huge challenge in
the past because as things are added to trunk, they become impossible to
detangle.

The "how it would work" made me think that perhaps there is a branch for
dec 1 with only features passing CI? I'm trying to avoid the problems we
have had in the past and wondering your idea of how to avoid those.

On Thu, Nov 13, 2025 at 7:24 AM Josh McKenzie  wrote:

> If we decided that Dec 1 is the cutoff, how would that work?
>
> What do you mean? I don't understand the question =/
>
> To the question about user confusion, I think Jeremiah covers it.
> 6.0-beta1 and 7.0-alpha1 clearly communicate the different scopes and
> levels of maturity of each release cycle even were they to be made
> available concurrently.
>
> On Wed, Nov 12, 2025, at 2:35 PM, Patrick McFadin wrote:
>
> Imagining how this would work. If we decided that Dec 1 is the cutoff, how
> would that work?
>
>
>

Re: [DISCUSS] Proposal: formalize release cadence and alphas from trunk

[Isaac Reath]

+1 to the original proposal (quarterly alphas + yearly major cadence) as
well as aligning subprojects to the same cadence as a north star. I also
think it would make sense to surface the cadence on the cassandra.apache.org
website (perhaps on the downloads page?) so that users can understand the
release cycle and can plan accordingly.

On Thu, Nov 13, 2025 at 12:51 PM Štefan Miklošovič 
wrote:

> btw if we release Cassandra quarterly then for subprojects it will be
> at most 3 months until whatever lands in the trunk will be available
> for integration. That is a way better model than waiting
> god-knows-how-long. Being able to integrate into suprojects in 3
> months at max is pretty good, we can follow what is going on in the
> trunk more closely, while still having their discretion in releasing
> however they see fit.
>
> I think that, presented like this, will solve a lot of issues I have
> mentioned previously.
>
> On Thu, Nov 13, 2025 at 6:13 PM Josh McKenzie 
> wrote:
> >
> > we would be basically releasing "all the time" so I
> > would welcome it if other people start to participate in releases as
> > well or we make it more manageable
> >
> > IMO releasing should be almost completely automated and simple outside
> running the voting thread. A predictable cadence like this for just the
> core project, much less for all subprojects, will force our hand on
> automating everything that's not already (including PMC members certifying
> releases for their vote).
> >
> > I plan to focus on that once I have the JDK21 stuff ironed out.
> >
> > On Thu, Nov 13, 2025, at 11:19 AM, Ekaterina Dimitrova wrote:
> >
> > I like how Bernardo called it - North star. My proposal - let’s align
> the process between the main and the subprojects, and if at the end of a
> quarter it doesn’t make sense for a subproject to have a release - bring it
> here and agree to skip it.
> >
> > On Thu, 13 Nov 2025 at 11:03, Štefan Miklošovič 
> wrote:
> >
> > That is a reasonable proposal - to at least somehow align subprojects
> > with the main Cassandra repository. Cassandra is integrating with e.g.
> > Cassandra Analytics and a lot of times Analytics integrates with what
> > is happening in core Cassandra. The situation now is that even if the
> > feature is in Cassandra's trunk we can not integrate it into Analytics
> > (e.g. writing SSTables with a ZSTD compression dictionary from Spark
> > jobs, or constraints) because there is actually "nothing to integrate
> > with" when Cassandra is not released yet. I think this could speed up
> > the delivery of features because for now we just wait till 6.0 is out
> > to start to integrate it, basically (or we can integrate it already if
> > we run on some concrete commit in trunk but developing against that is
> > like being on a quick sand).
> >
> > On the other hand, I am afraid that quarterly release schedule for
> > subprojects might be just "way too often". If there is not a lot of
> > traffic in subprojects then sticking to releasing it just for the sake
> > of it is not good either. I think there should be some actual
> > improvements / fixes etc. we want to release instead of just cutting
> > releases left and right "because it's time".
> >
> > This whole release proposal also puts committers / pmcs under more
> > stress / load as we would be basically releasing "all the time" so I
> > would welcome it if other people start to participate in releases as
> > well or we make it more manageable for the actual number of people
> > already actually releasing / verifying.
> >
> > On Thu, Nov 13, 2025 at 4:39 PM Bernardo Botella
> >  wrote:
> > >
> > > Hi,
> > >
> > > I would like to take the opportunity to discuss as well the
> possibility of adding the subprojects to this release cadence. I think the
> entire Apache Cassandra ecosystem would benefit from that consistent and
> predictable release schedules, and not only the main project.
> > >
> > > I see potential benefits from this for the subprojects other than the
> one discussed in this thread:
> > > - IMHO, this show consistency and care for our users.
> > > - The subprojects are also seen as first class citizens in the Apache
> Cassandra ecosystem.
> > >
> > > I understand that different subprojects are at different stages of
> releases, (aka, sidecar is under heavy development. Analytics is still
> fighting with some issues to release its 0.2.0 version, etc), that may (or
> may not) make them not suitable for the general release cadence that we all
> agree upon, but at least, aligning with that should be the North Star for
> everyone.
> > >
> > > Regards,
> > > Bernardo
> > >
> > >
> > > > On Nov 13, 2025, at 7:22 AM, Josh McKenzie 
> wrote:
> > > >
> > > >> If we decided that Dec 1 is the cutoff, how would that work?
> > > > What do you mean? I don't understand the question =/
> > > >
> > > > To the question about user confusion, I think Jeremiah covers it.
> 6.0-beta1 and 7.0-alpha1 clearly communicate the different scopes and

Re: [DISCUSS] Proposal: formalize release cadence and alphas from trunk

[Štefan Miklošovič]

btw if we release Cassandra quarterly then for subprojects it will be
at most 3 months until whatever lands in the trunk will be available
for integration. That is a way better model than waiting
god-knows-how-long. Being able to integrate into suprojects in 3
months at max is pretty good, we can follow what is going on in the
trunk more closely, while still having their discretion in releasing
however they see fit.

I think that, presented like this, will solve a lot of issues I have
mentioned previously.

On Thu, Nov 13, 2025 at 6:13 PM Josh McKenzie  wrote:
>
> we would be basically releasing "all the time" so I
> would welcome it if other people start to participate in releases as
> well or we make it more manageable
>
> IMO releasing should be almost completely automated and simple outside 
> running the voting thread. A predictable cadence like this for just the core 
> project, much less for all subprojects, will force our hand on automating 
> everything that's not already (including PMC members certifying releases for 
> their vote).
>
> I plan to focus on that once I have the JDK21 stuff ironed out.
>
> On Thu, Nov 13, 2025, at 11:19 AM, Ekaterina Dimitrova wrote:
>
> I like how Bernardo called it - North star. My proposal - let’s align the 
> process between the main and the subprojects, and if at the end of a quarter 
> it doesn’t make sense for a subproject to have a release - bring it here and 
> agree to skip it.
>
> On Thu, 13 Nov 2025 at 11:03, Štefan Miklošovič  
> wrote:
>
> That is a reasonable proposal - to at least somehow align subprojects
> with the main Cassandra repository. Cassandra is integrating with e.g.
> Cassandra Analytics and a lot of times Analytics integrates with what
> is happening in core Cassandra. The situation now is that even if the
> feature is in Cassandra's trunk we can not integrate it into Analytics
> (e.g. writing SSTables with a ZSTD compression dictionary from Spark
> jobs, or constraints) because there is actually "nothing to integrate
> with" when Cassandra is not released yet. I think this could speed up
> the delivery of features because for now we just wait till 6.0 is out
> to start to integrate it, basically (or we can integrate it already if
> we run on some concrete commit in trunk but developing against that is
> like being on a quick sand).
>
> On the other hand, I am afraid that quarterly release schedule for
> subprojects might be just "way too often". If there is not a lot of
> traffic in subprojects then sticking to releasing it just for the sake
> of it is not good either. I think there should be some actual
> improvements / fixes etc. we want to release instead of just cutting
> releases left and right "because it's time".
>
> This whole release proposal also puts committers / pmcs under more
> stress / load as we would be basically releasing "all the time" so I
> would welcome it if other people start to participate in releases as
> well or we make it more manageable for the actual number of people
> already actually releasing / verifying.
>
> On Thu, Nov 13, 2025 at 4:39 PM Bernardo Botella
>  wrote:
> >
> > Hi,
> >
> > I would like to take the opportunity to discuss as well the possibility of 
> > adding the subprojects to this release cadence. I think the entire Apache 
> > Cassandra ecosystem would benefit from that consistent and predictable 
> > release schedules, and not only the main project.
> >
> > I see potential benefits from this for the subprojects other than the one 
> > discussed in this thread:
> > - IMHO, this show consistency and care for our users.
> > - The subprojects are also seen as first class citizens in the Apache 
> > Cassandra ecosystem.
> >
> > I understand that different subprojects are at different stages of 
> > releases, (aka, sidecar is under heavy development. Analytics is still 
> > fighting with some issues to release its 0.2.0 version, etc), that may (or 
> > may not) make them not suitable for the general release cadence that we all 
> > agree upon, but at least, aligning with that should be the North Star for 
> > everyone.
> >
> > Regards,
> > Bernardo
> >
> >
> > > On Nov 13, 2025, at 7:22 AM, Josh McKenzie  wrote:
> > >
> > >> If we decided that Dec 1 is the cutoff, how would that work?
> > > What do you mean? I don't understand the question =/
> > >
> > > To the question about user confusion, I think Jeremiah covers it. 
> > > 6.0-beta1 and 7.0-alpha1 clearly communicate the different scopes and 
> > > levels of maturity of each release cycle even were they to be made 
> > > available concurrently.
> > >
> > > On Wed, Nov 12, 2025, at 2:35 PM, Patrick McFadin wrote:
> > >> Imagining how this would work. If we decided that Dec 1 is the cutoff, 
> > >> how would that work?
> > >>
> > >
> >
>
>

Re: [DISCUSS] Proposal: formalize release cadence and alphas from trunk

[Josh McKenzie]

> we would be basically releasing "all the time" so I
> would welcome it if other people start to participate in releases as
> well or we make it more manageable
IMO releasing should be almost completely automated and simple outside running 
the voting thread. A predictable cadence like this for just the core project, 
much less for all subprojects, will force our hand on automating everything 
that's not already (including PMC members certifying releases for their vote).

I plan to focus on that once I have the JDK21 stuff ironed out.

On Thu, Nov 13, 2025, at 11:19 AM, Ekaterina Dimitrova wrote:
> I like how Bernardo called it - North star. My proposal - let’s align the 
> process between the main and the subprojects, and if at the end of a quarter 
> it doesn’t make sense for a subproject to have a release - bring it here and 
> agree to skip it.
> 
> On Thu, 13 Nov 2025 at 11:03, Štefan Miklošovič  
> wrote:
>> That is a reasonable proposal - to at least somehow align subprojects
>> with the main Cassandra repository. Cassandra is integrating with e.g.
>> Cassandra Analytics and a lot of times Analytics integrates with what
>> is happening in core Cassandra. The situation now is that even if the
>> feature is in Cassandra's trunk we can not integrate it into Analytics
>> (e.g. writing SSTables with a ZSTD compression dictionary from Spark
>> jobs, or constraints) because there is actually "nothing to integrate
>> with" when Cassandra is not released yet. I think this could speed up
>> the delivery of features because for now we just wait till 6.0 is out
>> to start to integrate it, basically (or we can integrate it already if
>> we run on some concrete commit in trunk but developing against that is
>> like being on a quick sand).
>> 
>> On the other hand, I am afraid that quarterly release schedule for
>> subprojects might be just "way too often". If there is not a lot of
>> traffic in subprojects then sticking to releasing it just for the sake
>> of it is not good either. I think there should be some actual
>> improvements / fixes etc. we want to release instead of just cutting
>> releases left and right "because it's time".
>> 
>> This whole release proposal also puts committers / pmcs under more
>> stress / load as we would be basically releasing "all the time" so I
>> would welcome it if other people start to participate in releases as
>> well or we make it more manageable for the actual number of people
>> already actually releasing / verifying.
>> 
>> On Thu, Nov 13, 2025 at 4:39 PM Bernardo Botella
>>  wrote:
>> >
>> > Hi,
>> >
>> > I would like to take the opportunity to discuss as well the possibility of 
>> > adding the subprojects to this release cadence. I think the entire Apache 
>> > Cassandra ecosystem would benefit from that consistent and predictable 
>> > release schedules, and not only the main project.
>> >
>> > I see potential benefits from this for the subprojects other than the one 
>> > discussed in this thread:
>> > - IMHO, this show consistency and care for our users.
>> > - The subprojects are also seen as first class citizens in the Apache 
>> > Cassandra ecosystem.
>> >
>> > I understand that different subprojects are at different stages of 
>> > releases, (aka, sidecar is under heavy development. Analytics is still 
>> > fighting with some issues to release its 0.2.0 version, etc), that may (or 
>> > may not) make them not suitable for the general release cadence that we 
>> > all agree upon, but at least, aligning with that should be the North Star 
>> > for everyone.
>> >
>> > Regards,
>> > Bernardo
>> >
>> >
>> > > On Nov 13, 2025, at 7:22 AM, Josh McKenzie  wrote:
>> > >
>> > >> If we decided that Dec 1 is the cutoff, how would that work?
>> > > What do you mean? I don't understand the question =/
>> > >
>> > > To the question about user confusion, I think Jeremiah covers it. 
>> > > 6.0-beta1 and 7.0-alpha1 clearly communicate the different scopes and 
>> > > levels of maturity of each release cycle even were they to be made 
>> > > available concurrently.
>> > >
>> > > On Wed, Nov 12, 2025, at 2:35 PM, Patrick McFadin wrote:
>> > >> Imagining how this would work. If we decided that Dec 1 is the cutoff, 
>> > >> how would that work?
>> > >>
>> > >
>> >

Re: [DISCUSS] Proposal: formalize release cadence and alphas from trunk

[Ekaterina Dimitrova]

I like how Bernardo called it - North star. My proposal - let’s align the
process between the main and the subprojects, and if at the end of a
quarter it doesn’t make sense for a subproject to have a release - bring it
here and agree to skip it.

On Thu, 13 Nov 2025 at 11:03, Štefan Miklošovič 
wrote:

> That is a reasonable proposal - to at least somehow align subprojects
> with the main Cassandra repository. Cassandra is integrating with e.g.
> Cassandra Analytics and a lot of times Analytics integrates with what
> is happening in core Cassandra. The situation now is that even if the
> feature is in Cassandra's trunk we can not integrate it into Analytics
> (e.g. writing SSTables with a ZSTD compression dictionary from Spark
> jobs, or constraints) because there is actually "nothing to integrate
> with" when Cassandra is not released yet. I think this could speed up
> the delivery of features because for now we just wait till 6.0 is out
> to start to integrate it, basically (or we can integrate it already if
> we run on some concrete commit in trunk but developing against that is
> like being on a quick sand).
>
> On the other hand, I am afraid that quarterly release schedule for
> subprojects might be just "way too often". If there is not a lot of
> traffic in subprojects then sticking to releasing it just for the sake
> of it is not good either. I think there should be some actual
> improvements / fixes etc. we want to release instead of just cutting
> releases left and right "because it's time".
>
> This whole release proposal also puts committers / pmcs under more
> stress / load as we would be basically releasing "all the time" so I
> would welcome it if other people start to participate in releases as
> well or we make it more manageable for the actual number of people
> already actually releasing / verifying.
>
> On Thu, Nov 13, 2025 at 4:39 PM Bernardo Botella
>  wrote:
> >
> > Hi,
> >
> > I would like to take the opportunity to discuss as well the possibility
> of adding the subprojects to this release cadence. I think the entire
> Apache Cassandra ecosystem would benefit from that consistent and
> predictable release schedules, and not only the main project.
> >
> > I see potential benefits from this for the subprojects other than the
> one discussed in this thread:
> > - IMHO, this show consistency and care for our users.
> > - The subprojects are also seen as first class citizens in the Apache
> Cassandra ecosystem.
> >
> > I understand that different subprojects are at different stages of
> releases, (aka, sidecar is under heavy development. Analytics is still
> fighting with some issues to release its 0.2.0 version, etc), that may (or
> may not) make them not suitable for the general release cadence that we all
> agree upon, but at least, aligning with that should be the North Star for
> everyone.
> >
> > Regards,
> > Bernardo
> >
> >
> > > On Nov 13, 2025, at 7:22 AM, Josh McKenzie 
> wrote:
> > >
> > >> If we decided that Dec 1 is the cutoff, how would that work?
> > > What do you mean? I don't understand the question =/
> > >
> > > To the question about user confusion, I think Jeremiah covers it.
> 6.0-beta1 and 7.0-alpha1 clearly communicate the different scopes and
> levels of maturity of each release cycle even were they to be made
> available concurrently.
> > >
> > > On Wed, Nov 12, 2025, at 2:35 PM, Patrick McFadin wrote:
> > >> Imagining how this would work. If we decided that Dec 1 is the
> cutoff, how would that work?
> > >>
> > >
> >
>

Re: [DISCUSS] Proposal: formalize release cadence and alphas from trunk

[Štefan Miklošovič]

That is a reasonable proposal - to at least somehow align subprojects
with the main Cassandra repository. Cassandra is integrating with e.g.
Cassandra Analytics and a lot of times Analytics integrates with what
is happening in core Cassandra. The situation now is that even if the
feature is in Cassandra's trunk we can not integrate it into Analytics
(e.g. writing SSTables with a ZSTD compression dictionary from Spark
jobs, or constraints) because there is actually "nothing to integrate
with" when Cassandra is not released yet. I think this could speed up
the delivery of features because for now we just wait till 6.0 is out
to start to integrate it, basically (or we can integrate it already if
we run on some concrete commit in trunk but developing against that is
like being on a quick sand).

On the other hand, I am afraid that quarterly release schedule for
subprojects might be just "way too often". If there is not a lot of
traffic in subprojects then sticking to releasing it just for the sake
of it is not good either. I think there should be some actual
improvements / fixes etc. we want to release instead of just cutting
releases left and right "because it's time".

This whole release proposal also puts committers / pmcs under more
stress / load as we would be basically releasing "all the time" so I
would welcome it if other people start to participate in releases as
well or we make it more manageable for the actual number of people
already actually releasing / verifying.

On Thu, Nov 13, 2025 at 4:39 PM Bernardo Botella
 wrote:
>
> Hi,
>
> I would like to take the opportunity to discuss as well the possibility of 
> adding the subprojects to this release cadence. I think the entire Apache 
> Cassandra ecosystem would benefit from that consistent and predictable 
> release schedules, and not only the main project.
>
> I see potential benefits from this for the subprojects other than the one 
> discussed in this thread:
> - IMHO, this show consistency and care for our users.
> - The subprojects are also seen as first class citizens in the Apache 
> Cassandra ecosystem.
>
> I understand that different subprojects are at different stages of releases, 
> (aka, sidecar is under heavy development. Analytics is still fighting with 
> some issues to release its 0.2.0 version, etc), that may (or may not) make 
> them not suitable for the general release cadence that we all agree upon, but 
> at least, aligning with that should be the North Star for everyone.
>
> Regards,
> Bernardo
>
>
> > On Nov 13, 2025, at 7:22 AM, Josh McKenzie  wrote:
> >
> >> If we decided that Dec 1 is the cutoff, how would that work?
> > What do you mean? I don't understand the question =/
> >
> > To the question about user confusion, I think Jeremiah covers it. 6.0-beta1 
> > and 7.0-alpha1 clearly communicate the different scopes and levels of 
> > maturity of each release cycle even were they to be made available 
> > concurrently.
> >
> > On Wed, Nov 12, 2025, at 2:35 PM, Patrick McFadin wrote:
> >> Imagining how this would work. If we decided that Dec 1 is the cutoff, how 
> >> would that work?
> >>
> >
>

Re: [DISCUSS] Proposal: formalize release cadence and alphas from trunk

[Bernardo Botella]

Hi,

I would like to take the opportunity to discuss as well the possibility of 
adding the subprojects to this release cadence. I think the entire Apache 
Cassandra ecosystem would benefit from that consistent and predictable release 
schedules, and not only the main project.

I see potential benefits from this for the subprojects other than the one 
discussed in this thread:
- IMHO, this show consistency and care for our users.
- The subprojects are also seen as first class citizens in the Apache Cassandra 
ecosystem.

I understand that different subprojects are at different stages of releases, 
(aka, sidecar is under heavy development. Analytics is still fighting with some 
issues to release its 0.2.0 version, etc), that may (or may not) make them not 
suitable for the general release cadence that we all agree upon, but at least, 
aligning with that should be the North Star for everyone.

Regards,
Bernardo


> On Nov 13, 2025, at 7:22 AM, Josh McKenzie  wrote:
> 
>> If we decided that Dec 1 is the cutoff, how would that work?
> What do you mean? I don't understand the question =/
> 
> To the question about user confusion, I think Jeremiah covers it. 6.0-beta1 
> and 7.0-alpha1 clearly communicate the different scopes and levels of 
> maturity of each release cycle even were they to be made available 
> concurrently.
> 
> On Wed, Nov 12, 2025, at 2:35 PM, Patrick McFadin wrote:
>> Imagining how this would work. If we decided that Dec 1 is the cutoff, how 
>> would that work?
>> 
> 

Re: [DISCUSS] Proposal: formalize release cadence and alphas from trunk

[Josh McKenzie]

> If we decided that Dec 1 is the cutoff, how would that work?
What do you mean? I don't understand the question =/

To the question about user confusion, I think Jeremiah covers it. 6.0-beta1 and 
7.0-alpha1 clearly communicate the different scopes and levels of maturity of 
each release cycle even were they to be made available concurrently.

On Wed, Nov 12, 2025, at 2:35 PM, Patrick McFadin wrote:
> Imagining how this would work. If we decided that Dec 1 is the cutoff, how 
> would that work?
> 

Re: [DISCUSS] Proposal: formalize release cadence and alphas from trunk

[Patrick McFadin]

Imagining how this would work. If we decided that Dec 1 is the cutoff, how 
would that work?

I am totally onboard with the train model, which I thought we were trying to do.

I am also +1 on doing snapshot or nightly builds on a green CI build. (I know. 
That requires a green CI) 

> On Nov 12, 2025, at 11:26 AM, David Capwell  wrote:
> 
> I was just talking to Scott about this minutes ago… thanks for bringing this 
> up again!
> 
> I am a strong +1 to hard dates where we cut the branch; the more it's human 
> driven, the harder it is to actually do it and agree to cut.
> 
> 
>> On Nov 12, 2025, at 10:54 AM, Ekaterina Dimitrova  
>> wrote:
>> 
>> Yeah, cutting branch in beta (as Mick suggested) actually covers that so my 
>> example is invalid.
>> 
>> We would just ensure that we will have more regular beta I guess until we 
>> get to RC (instead of interleaving alpha)
>> 
>> On Wed, 12 Nov 2025 at 13:48, Jeremiah Jordan > > wrote:
>>> As long as we change the definition I guess that's ok. It does seem strange 
>>> to me to call something alpha1 that has a planned 9 more months of features 
>>> going into it.
>>> 
>>> 
>>> > Then my question is - if we have 2 quarters between, let’s say beta and 
>>> > rc - do we have alphas in the mean time? That would be confusing from 
>>> > user’s perspective
>>> 
>>> 
>>> I think this would be fine. The alpha would be for the next release. So you 
>>> would have:
>>> 
>>> 6.0-beta1 cut in Jan. trunk would become 7.0.
>>> 
>>> In April assuming it hadn't GA'ed there would be 6.0-beta10 or 6.0-rc2 or 
>>> similar as the latest on 6.0
>>> 
>>> 7.0-alpha1 would be cut from trunk in April.
>>> 
>>> Ideally we could get 6.0.0 GA out before the 7.0-alpha1 is cut. But I don't 
>>> think that's a requirement. Depending on how long it takes to stabilize the 
>>> release we might need to re-think the cadence of cutting beta1's. But I 
>>> would give a few tries before doing that. The first time is likely going to 
>>> be the worst.
>>> 
>>> 
>>> 
>>> 
>>> -Jeremiah
>>> 
>>> 
>>> On Wed, Nov 12, 2025 at 9:59 AM Ekaterina Dimitrova >> > wrote:
 Then my question is - if we have 2 quarters between, let’s say beta and rc 
 - do we have alphas in the mean time? That would be confusing from user’s 
 perspective
 
 On Wed, 12 Nov 2025 at 10:20, Josh McKenzie >>> > wrote:
>> Josh, in your example, we go apha 3->beta->rc->ga in three months? 
> I didn't really speak to the time frame for the beta -> rc -> ga 
> transition. History indicates that could take shorter or longer (probably 
> longer) and we should probably just let it take what it takes.
> 
> On Wed, Nov 12, 2025, at 10:14 AM, Ekaterina Dimitrova wrote:
>> Ops, too quick. Please
>> “
>> Josh, in your example, we go beta to alpha 3->beta->rc->ga in three 
>> months? ”
>> 
>> To be read:
>> “
>> Josh, in your example, we go alpha 3->beta->rc->ga in three months? ”
>> 
>> On Wed, 12 Nov 2025 at 10:13, Ekaterina Dimitrova > > wrote:
>> I am with Josh on formalizing/documenting so we do not have to revisit 
>> old dev mails every now and then and it is clear for new contributors. 
>> Thanks
>> 
>> Regarding alpha - as long as we tweak the text in our release lifecycle 
>> and make things clear - reality matches the release lyfecycle doc - I am 
>> fine with alpha. 
>> 
>> “
>> I'm w/Mick and I think we could just make it a structured. Something 
>> like the following:
>> Jan 1: cut branch for next major from trunk, release version -beta1 (or 
>> whatever doesn't break our infra)
>> Stabilize it and GA when CI is green and important bugs are fixed
>> April 1: cut release from trunk as -alpha1
>> July 1: cut release from trunk as -alpha2
>> Oct 1: cut release from trunk as -alpha3
>> Jan 1: GOTO Jan 1 above”
>> 
>> Josh, in your example, we go beta to alpha 3->beta->rc->ga in three 
>> months? 
>> 
>> Best regards,
>> Ekaterina
>> 
>> On Wed, 12 Nov 2025 at 10:06, Josh McKenzie > > wrote:
>> 
>>> I think we have had consensus to release every 12 months a few times 
>>> now.
>> I think we have too but we never formalized it so end up re-litigating 
>> it. That kind of re-litigation is a smell to me so I tend to try and 
>> push for formalization to try and remove wasted effort. I think it's 
>> also helpful for new contributors coming on board to have guidance 
>> around these things in one place rather than needing to dig through 
>> email archives. And taking this from "something we talk about on the dev 
>> list and agree with" to "something we operationalize and execute on" is 
>> still a WIP. :)
>> 
>> I'm w/Mick and I think we could just make

Re: [DISCUSS] Proposal: formalize release cadence and alphas from trunk

[David Capwell]

I was just talking to Scott about this minutes ago… thanks for bringing this up 
again!

I am a strong +1 to hard dates where we cut the branch; the more it's human 
driven, the harder it is to actually do it and agree to cut.


> On Nov 12, 2025, at 10:54 AM, Ekaterina Dimitrova  
> wrote:
> 
> Yeah, cutting branch in beta (as Mick suggested) actually covers that so my 
> example is invalid.
> 
> We would just ensure that we will have more regular beta I guess until we get 
> to RC (instead of interleaving alpha)
> 
> On Wed, 12 Nov 2025 at 13:48, Jeremiah Jordan  > wrote:
>> As long as we change the definition I guess that's ok. It does seem strange 
>> to me to call something alpha1 that has a planned 9 more months of features 
>> going into it.
>> 
>> 
>> > Then my question is - if we have 2 quarters between, let’s say beta and rc 
>> > - do we have alphas in the mean time? That would be confusing from user’s 
>> > perspective
>> 
>> 
>> I think this would be fine. The alpha would be for the next release. So you 
>> would have:
>> 
>> 6.0-beta1 cut in Jan. trunk would become 7.0.
>> 
>> In April assuming it hadn't GA'ed there would be 6.0-beta10 or 6.0-rc2 or 
>> similar as the latest on 6.0
>> 
>> 7.0-alpha1 would be cut from trunk in April.
>> 
>> Ideally we could get 6.0.0 GA out before the 7.0-alpha1 is cut. But I don't 
>> think that's a requirement. Depending on how long it takes to stabilize the 
>> release we might need to re-think the cadence of cutting beta1's. But I 
>> would give a few tries before doing that. The first time is likely going to 
>> be the worst.
>> 
>> 
>> 
>> 
>> -Jeremiah
>> 
>> 
>> On Wed, Nov 12, 2025 at 9:59 AM Ekaterina Dimitrova > > wrote:
>>> Then my question is - if we have 2 quarters between, let’s say beta and rc 
>>> - do we have alphas in the mean time? That would be confusing from user’s 
>>> perspective
>>> 
>>> On Wed, 12 Nov 2025 at 10:20, Josh McKenzie >> > wrote:
> Josh, in your example, we go apha 3->beta->rc->ga in three months? 
 I didn't really speak to the time frame for the beta -> rc -> ga 
 transition. History indicates that could take shorter or longer (probably 
 longer) and we should probably just let it take what it takes.
 
 On Wed, Nov 12, 2025, at 10:14 AM, Ekaterina Dimitrova wrote:
> Ops, too quick. Please
> “
> Josh, in your example, we go beta to alpha 3->beta->rc->ga in three 
> months? ”
> 
> To be read:
> “
> Josh, in your example, we go alpha 3->beta->rc->ga in three months? ”
> 
> On Wed, 12 Nov 2025 at 10:13, Ekaterina Dimitrova  > wrote:
> I am with Josh on formalizing/documenting so we do not have to revisit 
> old dev mails every now and then and it is clear for new contributors. 
> Thanks
> 
> Regarding alpha - as long as we tweak the text in our release lifecycle 
> and make things clear - reality matches the release lyfecycle doc - I am 
> fine with alpha. 
> 
> “
> I'm w/Mick and I think we could just make it a structured. Something like 
> the following:
> Jan 1: cut branch for next major from trunk, release version -beta1 (or 
> whatever doesn't break our infra)
> Stabilize it and GA when CI is green and important bugs are fixed
> April 1: cut release from trunk as -alpha1
> July 1: cut release from trunk as -alpha2
> Oct 1: cut release from trunk as -alpha3
> Jan 1: GOTO Jan 1 above”
> 
> Josh, in your example, we go beta to alpha 3->beta->rc->ga in three 
> months? 
> 
> Best regards,
> Ekaterina
> 
> On Wed, 12 Nov 2025 at 10:06, Josh McKenzie  > wrote:
> 
>> I think we have had consensus to release every 12 months a few times now.
> I think we have too but we never formalized it so end up re-litigating 
> it. That kind of re-litigation is a smell to me so I tend to try and push 
> for formalization to try and remove wasted effort. I think it's also 
> helpful for new contributors coming on board to have guidance around 
> these things in one place rather than needing to dig through email 
> archives. And taking this from "something we talk about on the dev list 
> and agree with" to "something we operationalize and execute on" is still 
> a WIP. :)
> 
> I'm w/Mick and I think we could just make it a structured. Something like 
> the following:
> Jan 1: cut branch for next major from trunk, release version -beta1 (or 
> whatever doesn't break our infra)
> Stabilize it and GA when CI is green and important bugs are fixed
> April 1: cut release from trunk as -alpha1
> July 1: cut release from trunk as -alpha2
> Oct 1: cut release from trunk as -alpha3
> Jan 1: GOTO Jan 1 above
> So:
> Train goes out when it's scheduled

Re: [DISCUSS] Proposal: formalize release cadence and alphas from trunk

[Ekaterina Dimitrova]

Yeah, cutting branch in beta (as Mick suggested) actually covers that so my
example is invalid.

We would just ensure that we will have more regular beta I guess until we
get to RC (instead of interleaving alpha)

On Wed, 12 Nov 2025 at 13:48, Jeremiah Jordan  wrote:

> As long as we change the definition I guess that's ok. It does seem
> strange to me to call something alpha1 that has a planned 9 more months of
> features going into it.
>
>
> > Then my question is - if we have 2 quarters between, let’s say beta and
> rc - do we have alphas in the mean time? That would be confusing from
> user’s perspective
>
>
> I think this would be fine. The alpha would be for the next release. So
> you would have:
>
> 6.0-beta1 cut in Jan. trunk would become 7.0.
>
> In April assuming it hadn't GA'ed there would be 6.0-beta10 or 6.0-rc2 or
> similar as the latest on 6.0
>
> 7.0-alpha1 would be cut from trunk in April.
>
> Ideally we could get 6.0.0 GA out before the 7.0-alpha1 is cut. But I
> don't think that's a requirement. Depending on how long it takes to
> stabilize the release we might need to re-think the cadence of cutting
> beta1's. But I would give a few tries before doing that. The first time is
> likely going to be the worst.
>
>
>
>
> -Jeremiah
>
>
> On Wed, Nov 12, 2025 at 9:59 AM Ekaterina Dimitrova 
> wrote:
>
>> Then my question is - if we have 2 quarters between, let’s say beta and
>> rc - do we have alphas in the mean time? That would be confusing from
>> user’s perspective
>>
>> On Wed, 12 Nov 2025 at 10:20, Josh McKenzie  wrote:
>>
>>> Josh, in your example, we go apha 3->beta->rc->ga in three months?
>>>
>>> I didn't really speak to the time frame for the beta -> rc -> ga
>>> transition. History indicates that could take shorter or longer (probably
>>> longer) and we should probably just let it take what it takes.
>>>
>>> On Wed, Nov 12, 2025, at 10:14 AM, Ekaterina Dimitrova wrote:
>>>
>>> Ops, too quick. Please
>>> “
>>> Josh, in your example, we go beta to alpha 3->beta->rc->ga in three
>>> months? ”
>>>
>>> To be read:
>>> “
>>> Josh, in your example, we go alpha 3->beta->rc->ga in three months? ”
>>>
>>> On Wed, 12 Nov 2025 at 10:13, Ekaterina Dimitrova 
>>> wrote:
>>>
>>> I am with Josh on formalizing/documenting so we do not have to revisit
>>> old dev mails every now and then and it is clear for new contributors.
>>> Thanks
>>>
>>> Regarding alpha - as long as we tweak the text in our release lifecycle
>>> and make things clear - reality matches the release lyfecycle doc - I am
>>> fine with alpha.
>>>
>>> “
>>> I'm w/Mick and I think we could just make it a structured. Something
>>> like the following:
>>>
>>>- Jan 1: cut branch for next major from trunk, release version
>>>-beta1 (or whatever doesn't break our infra)
>>>-
>>>   - Stabilize it and GA when CI is green and important bugs are
>>>   fixed
>>>- April 1: cut release from trunk as -alpha1
>>>- July 1: cut release from trunk as -alpha2
>>>- Oct 1: cut release from trunk as -alpha3
>>>- Jan 1: GOTO Jan 1 above”
>>>
>>>
>>> Josh, in your example, we go beta to alpha 3->beta->rc->ga in three
>>> months?
>>>
>>> Best regards,
>>> Ekaterina
>>>
>>> On Wed, 12 Nov 2025 at 10:06, Josh McKenzie 
>>> wrote:
>>>
>>>
>>> I think we have had consensus to release every 12 months a few times now.
>>>
>>> I think we have too but we never formalized it so end up re-litigating
>>> it. That kind of re-litigation is a smell to me so I tend to try and push
>>> for formalization to try and remove wasted effort. I think it's also
>>> helpful for new contributors coming on board to have guidance around these
>>> things in one place rather than needing to dig through email archives. And
>>> taking this from "something we talk about on the dev list and agree with"
>>> to "something we operationalize and execute on" is still a WIP. :)
>>>
>>> I'm w/Mick and I think we could just make it a structured. Something
>>> like the following:
>>>
>>>
>>>- Jan 1: cut branch for next major from trunk, release version
>>>-beta1 (or whatever doesn't break our infra)
>>>   - Stabilize it and GA when CI is green and important bugs are
>>>   fixed
>>>- April 1: cut release from trunk as -alpha1
>>>- July 1: cut release from trunk as -alpha2
>>>- Oct 1: cut release from trunk as -alpha3
>>>- Jan 1: GOTO Jan 1 above
>>>
>>> So:
>>>
>>>1. Train goes out when it's scheduled
>>>2. Any feature merged throughout the year at worst has a 3 month lag
>>>between merge and availability in an alpha
>>>3. Any feature merged throughout the year that is promoted from
>>>experimental has at most a 12 month lag on availability in a stable GA
>>>release
>>>
>>>
>>> On Wed, Nov 12, 2025, at 5:17 AM, Mick wrote:
>>>
>>> -1 on the SNAPSHOT terminology in any release.  It (by popular use)
>>> implies mutable artefacts (e.g, hidden timestamped artefacts of the same
>>> version and unpinned dependencies).

Re: [DISCUSS] Proposal: formalize release cadence and alphas from trunk

[Jeremiah Jordan]

As long as we change the definition I guess that's ok. It does seem strange
to me to call something alpha1 that has a planned 9 more months of features
going into it.


> Then my question is - if we have 2 quarters between, let’s say beta and
rc - do we have alphas in the mean time? That would be confusing from
user’s perspective


I think this would be fine. The alpha would be for the next release. So you
would have:

6.0-beta1 cut in Jan. trunk would become 7.0.

In April assuming it hadn't GA'ed there would be 6.0-beta10 or 6.0-rc2 or
similar as the latest on 6.0

7.0-alpha1 would be cut from trunk in April.

Ideally we could get 6.0.0 GA out before the 7.0-alpha1 is cut. But I don't
think that's a requirement. Depending on how long it takes to stabilize the
release we might need to re-think the cadence of cutting beta1's. But I
would give a few tries before doing that. The first time is likely going to
be the worst.



-Jeremiah


On Wed, Nov 12, 2025 at 9:59 AM Ekaterina Dimitrova 
wrote:

> Then my question is - if we have 2 quarters between, let’s say beta and rc
> - do we have alphas in the mean time? That would be confusing from user’s
> perspective
>
> On Wed, 12 Nov 2025 at 10:20, Josh McKenzie  wrote:
>
>> Josh, in your example, we go apha 3->beta->rc->ga in three months?
>>
>> I didn't really speak to the time frame for the beta -> rc -> ga
>> transition. History indicates that could take shorter or longer (probably
>> longer) and we should probably just let it take what it takes.
>>
>> On Wed, Nov 12, 2025, at 10:14 AM, Ekaterina Dimitrova wrote:
>>
>> Ops, too quick. Please
>> “
>> Josh, in your example, we go beta to alpha 3->beta->rc->ga in three
>> months? ”
>>
>> To be read:
>> “
>> Josh, in your example, we go alpha 3->beta->rc->ga in three months? ”
>>
>> On Wed, 12 Nov 2025 at 10:13, Ekaterina Dimitrova 
>> wrote:
>>
>> I am with Josh on formalizing/documenting so we do not have to revisit
>> old dev mails every now and then and it is clear for new contributors.
>> Thanks
>>
>> Regarding alpha - as long as we tweak the text in our release lifecycle
>> and make things clear - reality matches the release lyfecycle doc - I am
>> fine with alpha.
>>
>> “
>> I'm w/Mick and I think we could just make it a structured. Something like
>> the following:
>>
>>- Jan 1: cut branch for next major from trunk, release version -beta1
>>(or whatever doesn't break our infra)
>>-
>>   - Stabilize it and GA when CI is green and important bugs are fixed
>>- April 1: cut release from trunk as -alpha1
>>- July 1: cut release from trunk as -alpha2
>>- Oct 1: cut release from trunk as -alpha3
>>- Jan 1: GOTO Jan 1 above”
>>
>>
>> Josh, in your example, we go beta to alpha 3->beta->rc->ga in three
>> months?
>>
>> Best regards,
>> Ekaterina
>>
>> On Wed, 12 Nov 2025 at 10:06, Josh McKenzie  wrote:
>>
>>
>> I think we have had consensus to release every 12 months a few times now.
>>
>> I think we have too but we never formalized it so end up re-litigating
>> it. That kind of re-litigation is a smell to me so I tend to try and push
>> for formalization to try and remove wasted effort. I think it's also
>> helpful for new contributors coming on board to have guidance around these
>> things in one place rather than needing to dig through email archives. And
>> taking this from "something we talk about on the dev list and agree with"
>> to "something we operationalize and execute on" is still a WIP. :)
>>
>> I'm w/Mick and I think we could just make it a structured. Something like
>> the following:
>>
>>
>>- Jan 1: cut branch for next major from trunk, release version -beta1
>>(or whatever doesn't break our infra)
>>   - Stabilize it and GA when CI is green and important bugs are fixed
>>- April 1: cut release from trunk as -alpha1
>>- July 1: cut release from trunk as -alpha2
>>- Oct 1: cut release from trunk as -alpha3
>>- Jan 1: GOTO Jan 1 above
>>
>> So:
>>
>>1. Train goes out when it's scheduled
>>2. Any feature merged throughout the year at worst has a 3 month lag
>>between merge and availability in an alpha
>>3. Any feature merged throughout the year that is promoted from
>>experimental has at most a 12 month lag on availability in a stable GA
>>release
>>
>>
>> On Wed, Nov 12, 2025, at 5:17 AM, Mick wrote:
>>
>> -1 on the SNAPSHOT terminology in any release.  It (by popular use)
>> implies mutable artefacts (e.g, hidden timestamped artefacts of the same
>> version and unpinned dependencies).   Such a thing can only be a nightly.
>> Our codebase also needs adjusting to deal with any qualifier that's not an
>> alpha/beta/rc, so if someone is suggesting not using one of those then they
>> should also be putting themselves forward to doing that work (meritocracy).
>>
>> My preference is alpha:  it fits into our existing release lifecycle
>> guidelines*, allows cutting releases rather than promotion from nightlies,
>> and it works

Re: [DISCUSS] Proposal: formalize release cadence and alphas from trunk

[Ekaterina Dimitrova]

Then my question is - if we have 2 quarters between, let’s say beta and rc
- do we have alphas in the mean time? That would be confusing from user’s
perspective

On Wed, 12 Nov 2025 at 10:20, Josh McKenzie  wrote:

> Josh, in your example, we go apha 3->beta->rc->ga in three months?
>
> I didn't really speak to the time frame for the beta -> rc -> ga
> transition. History indicates that could take shorter or longer (probably
> longer) and we should probably just let it take what it takes.
>
> On Wed, Nov 12, 2025, at 10:14 AM, Ekaterina Dimitrova wrote:
>
> Ops, too quick. Please
> “
> Josh, in your example, we go beta to alpha 3->beta->rc->ga in three
> months? ”
>
> To be read:
> “
> Josh, in your example, we go alpha 3->beta->rc->ga in three months? ”
>
> On Wed, 12 Nov 2025 at 10:13, Ekaterina Dimitrova 
> wrote:
>
> I am with Josh on formalizing/documenting so we do not have to revisit old
> dev mails every now and then and it is clear for new contributors. Thanks
>
> Regarding alpha - as long as we tweak the text in our release lifecycle
> and make things clear - reality matches the release lyfecycle doc - I am
> fine with alpha.
>
> “
> I'm w/Mick and I think we could just make it a structured. Something like
> the following:
>
>- Jan 1: cut branch for next major from trunk, release version -beta1
>(or whatever doesn't break our infra)
>-
>   - Stabilize it and GA when CI is green and important bugs are fixed
>- April 1: cut release from trunk as -alpha1
>- July 1: cut release from trunk as -alpha2
>- Oct 1: cut release from trunk as -alpha3
>- Jan 1: GOTO Jan 1 above”
>
>
> Josh, in your example, we go beta to alpha 3->beta->rc->ga in three
> months?
>
> Best regards,
> Ekaterina
>
> On Wed, 12 Nov 2025 at 10:06, Josh McKenzie  wrote:
>
>
> I think we have had consensus to release every 12 months a few times now.
>
> I think we have too but we never formalized it so end up re-litigating it.
> That kind of re-litigation is a smell to me so I tend to try and push for
> formalization to try and remove wasted effort. I think it's also helpful
> for new contributors coming on board to have guidance around these things
> in one place rather than needing to dig through email archives. And taking
> this from "something we talk about on the dev list and agree with" to
> "something we operationalize and execute on" is still a WIP. :)
>
> I'm w/Mick and I think we could just make it a structured. Something like
> the following:
>
>
>- Jan 1: cut branch for next major from trunk, release version -beta1
>(or whatever doesn't break our infra)
>   - Stabilize it and GA when CI is green and important bugs are fixed
>- April 1: cut release from trunk as -alpha1
>- July 1: cut release from trunk as -alpha2
>- Oct 1: cut release from trunk as -alpha3
>- Jan 1: GOTO Jan 1 above
>
> So:
>
>1. Train goes out when it's scheduled
>2. Any feature merged throughout the year at worst has a 3 month lag
>between merge and availability in an alpha
>3. Any feature merged throughout the year that is promoted from
>experimental has at most a 12 month lag on availability in a stable GA
>release
>
>
> On Wed, Nov 12, 2025, at 5:17 AM, Mick wrote:
>
> -1 on the SNAPSHOT terminology in any release.  It (by popular use)
> implies mutable artefacts (e.g, hidden timestamped artefacts of the same
> version and unpinned dependencies).   Such a thing can only be a nightly.
> Our codebase also needs adjusting to deal with any qualifier that's not an
> alpha/beta/rc, so if someone is suggesting not using one of those then they
> should also be putting themselves forward to doing that work (meritocracy).
>
> My preference is alpha:  it fits into our existing release lifecycle
> guidelines*, allows cutting releases rather than promotion from nightlies,
> and it works with the code as-is.
>
>
> *) the one item in our release lifecycle guidelines against Alpha that we
> need to relax is: "the system is mostly feature complete”.  My suggestion
> would be to bump that to the beta definition.   I think we should also bump
> "A new branch is created…" from GA down to Beta.
>
> Stefan, we would still go from alpha to beta.  And my understanding is we
> wouldn't necessarily jump to the first beta every 12 months– we still go
> through the lifecycle steps as deemed appropriate.
>
>
>
> > On 12 Nov 2025, at 02:40, Jeremiah Jordan  wrote:
> >
> > Same thoughts as Brandon. I think we have had consensus to release every
> 12 months a few times now. I am happy to continue with that as our North
> Star.
> > Do we want to pick some dates?
> > Maybe cut alpha in January. Optimistically run alphas and betas for 2-3
> months and then GAs would end up in March/April?
> >
> > Happy to cut SNAPSHOT releases through out the rest of the year. As
> suggested by Ekaterina, let’s not call them alpha releases, we already have
> a definition for that name.
> >
> > -Jeremiah
> >
> > On Tue, 

Re: [DISCUSS] Proposal: formalize release cadence and alphas from trunk

[Josh McKenzie]

> Josh, in your example, we go apha 3->beta->rc->ga in three months? 
I didn't really speak to the time frame for the beta -> rc -> ga transition. 
History indicates that could take shorter or longer (probably longer) and we 
should probably just let it take what it takes.

On Wed, Nov 12, 2025, at 10:14 AM, Ekaterina Dimitrova wrote:
> Ops, too quick. Please
> “
> Josh, in your example, we go beta to alpha 3->beta->rc->ga in three months? ”
> 
> To be read:
> “
> Josh, in your example, we go alpha 3->beta->rc->ga in three months? ”
> 
> On Wed, 12 Nov 2025 at 10:13, Ekaterina Dimitrova  
> wrote:
>> I am with Josh on formalizing/documenting so we do not have to revisit old 
>> dev mails every now and then and it is clear for new contributors. Thanks
>> 
>> Regarding alpha - as long as we tweak the text in our release lifecycle and 
>> make things clear - reality matches the release lyfecycle doc - I am fine 
>> with alpha. 
>> 
>> “
>> I'm w/Mick and I think we could just make it a structured. Something like 
>> the following:
>>  • Jan 1: cut branch for next major from trunk, release version -beta1 (or 
>> whatever doesn't break our infra)
>>  •• Stabilize it and GA when CI is green and important bugs are fixed
>>  • April 1: cut release from trunk as -alpha1
>>  • July 1: cut release from trunk as -alpha2
>>  • Oct 1: cut release from trunk as -alpha3
>>  • Jan 1: GOTO Jan 1 above”
>> 
>> Josh, in your example, we go beta to alpha 3->beta->rc->ga in three months? 
>> 
>> Best regards,
>> Ekaterina
>> 
>> On Wed, 12 Nov 2025 at 10:06, Josh McKenzie  wrote:
>>> __
 I think we have had consensus to release every 12 months a few times now.
>>> I think we have too but we never formalized it so end up re-litigating it. 
>>> That kind of re-litigation is a smell to me so I tend to try and push for 
>>> formalization to try and remove wasted effort. I think it's also helpful 
>>> for new contributors coming on board to have guidance around these things 
>>> in one place rather than needing to dig through email archives. And taking 
>>> this from "something we talk about on the dev list and agree with" to 
>>> "something we operationalize and execute on" is still a WIP. :)
>>> 
>>> I'm w/Mick and I think we could just make it a structured. Something like 
>>> the following:
>>>  • Jan 1: cut branch for next major from trunk, release version -beta1 (or 
>>> whatever doesn't break our infra)
>>>• Stabilize it and GA when CI is green and important bugs are fixed
>>>  • April 1: cut release from trunk as -alpha1
>>>  • July 1: cut release from trunk as -alpha2
>>>  • Oct 1: cut release from trunk as -alpha3
>>>  • Jan 1: GOTO Jan 1 above
>>> So:
>>>  1. Train goes out when it's scheduled
>>>  2. Any feature merged throughout the year at worst has a 3 month lag 
>>> between merge and availability in an alpha
>>>  3. Any feature merged throughout the year that is promoted from 
>>> experimental has at most a 12 month lag on availability in a stable GA 
>>> release
>>> 
>>> On Wed, Nov 12, 2025, at 5:17 AM, Mick wrote:
 -1 on the SNAPSHOT terminology in any release.  It (by popular use) 
 implies mutable artefacts (e.g, hidden timestamped artefacts of the same 
 version and unpinned dependencies).   Such a thing can only be a nightly.  
  Our codebase also needs adjusting to deal with any qualifier that's not 
 an alpha/beta/rc, so if someone is suggesting not using one of those then 
 they should also be putting themselves forward to doing that work 
 (meritocracy).
 
 My preference is alpha:  it fits into our existing release lifecycle 
 guidelines*, allows cutting releases rather than promotion from nightlies, 
 and it works with the code as-is.
 
 
 *) the one item in our release lifecycle guidelines against Alpha that we 
 need to relax is: "the system is mostly feature complete”.  My suggestion 
 would be to bump that to the beta definition.   I think we should also 
 bump "A new branch is created…" from GA down to Beta.
 
 Stefan, we would still go from alpha to beta.  And my understanding is we 
 wouldn't necessarily jump to the first beta every 12 months– we still go 
 through the lifecycle steps as deemed appropriate.
  
 
 
 > On 12 Nov 2025, at 02:40, Jeremiah Jordan  wrote:
 > 
 > Same thoughts as Brandon. I think we have had consensus to release every 
 > 12 months a few times now. I am happy to continue with that as our North 
 > Star.
 > Do we want to pick some dates?
 > Maybe cut alpha in January. Optimistically run alphas and betas for 2-3 
 > months and then GAs would end up in March/April?
 > 
 > Happy to cut SNAPSHOT releases through out the rest of the year. As 
 > suggested by Ekaterina, let’s not call them alpha releases, we already 
 > have a definition for that name.
 > 
 > -Jeremiah
 > 
 > On Tue, Nov 11, 2025 at 9:34 AM Br

Re: [DISCUSS] Proposal: formalize release cadence and alphas from trunk

[Ekaterina Dimitrova]

Ops, too quick. Please
“
Josh, in your example, we go beta to alpha 3->beta->rc->ga in three months?
”

To be read:
“
Josh, in your example, we go alpha 3->beta->rc->ga in three months? ”

On Wed, 12 Nov 2025 at 10:13, Ekaterina Dimitrova 
wrote:

> I am with Josh on formalizing/documenting so we do not have to revisit old
> dev mails every now and then and it is clear for new contributors. Thanks
>
> Regarding alpha - as long as we tweak the text in our release lifecycle
> and make things clear - reality matches the release lyfecycle doc - I am
> fine with alpha.
>
> “
> I'm w/Mick and I think we could just make it a structured. Something like
> the following:
>
>- Jan 1: cut branch for next major from trunk, release version -beta1
>(or whatever doesn't break our infra)
>-
>   - Stabilize it and GA when CI is green and important bugs are fixed
>- April 1: cut release from trunk as -alpha1
>- July 1: cut release from trunk as -alpha2
>- Oct 1: cut release from trunk as -alpha3
>- Jan 1: GOTO Jan 1 above”
>
>
> Josh, in your example, we go beta to alpha 3->beta->rc->ga in three
> months?
>
> Best regards,
> Ekaterina
>
> On Wed, 12 Nov 2025 at 10:06, Josh McKenzie  wrote:
>
>> I think we have had consensus to release every 12 months a few times now.
>>
>> I think we have too but we never formalized it so end up re-litigating
>> it. That kind of re-litigation is a smell to me so I tend to try and push
>> for formalization to try and remove wasted effort. I think it's also
>> helpful for new contributors coming on board to have guidance around these
>> things in one place rather than needing to dig through email archives. And
>> taking this from "something we talk about on the dev list and agree with"
>> to "something we operationalize and execute on" is still a WIP. :)
>>
>> I'm w/Mick and I think we could just make it a structured. Something like
>> the following:
>>
>
>>- Jan 1: cut branch for next major from trunk, release version -beta1
>>(or whatever doesn't break our infra)
>>   - Stabilize it and GA when CI is green and important bugs are fixed
>>- April 1: cut release from trunk as -alpha1
>>- July 1: cut release from trunk as -alpha2
>>- Oct 1: cut release from trunk as -alpha3
>>- Jan 1: GOTO Jan 1 above
>>
>> So:
>>
>>1. Train goes out when it's scheduled
>>2. Any feature merged throughout the year at worst has a 3 month lag
>>between merge and availability in an alpha
>>3. Any feature merged throughout the year that is promoted from
>>experimental has at most a 12 month lag on availability in a stable GA
>>release
>>
>>
>> On Wed, Nov 12, 2025, at 5:17 AM, Mick wrote:
>>
>> -1 on the SNAPSHOT terminology in any release.  It (by popular use)
>> implies mutable artefacts (e.g, hidden timestamped artefacts of the same
>> version and unpinned dependencies).   Such a thing can only be a nightly.
>> Our codebase also needs adjusting to deal with any qualifier that's not an
>> alpha/beta/rc, so if someone is suggesting not using one of those then they
>> should also be putting themselves forward to doing that work (meritocracy).
>>
>> My preference is alpha:  it fits into our existing release lifecycle
>> guidelines*, allows cutting releases rather than promotion from nightlies,
>> and it works with the code as-is.
>>
>>
>> *) the one item in our release lifecycle guidelines against Alpha that we
>> need to relax is: "the system is mostly feature complete”.  My suggestion
>> would be to bump that to the beta definition.   I think we should also bump
>> "A new branch is created…" from GA down to Beta.
>>
>> Stefan, we would still go from alpha to beta.  And my understanding is we
>> wouldn't necessarily jump to the first beta every 12 months– we still go
>> through the lifecycle steps as deemed appropriate.
>>
>>
>>
>> > On 12 Nov 2025, at 02:40, Jeremiah Jordan  wrote:
>> >
>> > Same thoughts as Brandon. I think we have had consensus to release
>> every 12 months a few times now. I am happy to continue with that as our
>> North Star.
>> > Do we want to pick some dates?
>> > Maybe cut alpha in January. Optimistically run alphas and betas for 2-3
>> months and then GAs would end up in March/April?
>> >
>> > Happy to cut SNAPSHOT releases through out the rest of the year. As
>> suggested by Ekaterina, let’s not call them alpha releases, we already have
>> a definition for that name.
>> >
>> > -Jeremiah
>> >
>> > On Tue, Nov 11, 2025 at 9:34 AM Brandon Williams 
>> wrote:
>> > I am +1 to releasing a major every 12 months, but I think we are
>> already attempting that, so we should clarify this is a train that leaves
>> at the agreed upon date, no exceptions.  I am +1 to cutting alphas as
>> frequently as desired, provided they are cut and not promoted from nightly.
>> >
>> > Kind Regards,
>> > Brandon
>> >
>> >
>> > On Tue, Nov 11, 2025 at 9:29 AM Josh McKenzie 
>> wrote:
>> > Is there anyone who's against releasing a major 

Re: [DISCUSS] Proposal: formalize release cadence and alphas from trunk

[Ekaterina Dimitrova]

I am with Josh on formalizing/documenting so we do not have to revisit old
dev mails every now and then and it is clear for new contributors. Thanks

Regarding alpha - as long as we tweak the text in our release lifecycle and
make things clear - reality matches the release lyfecycle doc - I am fine
with alpha.

“
I'm w/Mick and I think we could just make it a structured. Something like
the following:

   - Jan 1: cut branch for next major from trunk, release version -beta1
   (or whatever doesn't break our infra)
   -
  - Stabilize it and GA when CI is green and important bugs are fixed
   - April 1: cut release from trunk as -alpha1
   - July 1: cut release from trunk as -alpha2
   - Oct 1: cut release from trunk as -alpha3
   - Jan 1: GOTO Jan 1 above”


Josh, in your example, we go beta to alpha 3->beta->rc->ga in three months?

Best regards,
Ekaterina

On Wed, 12 Nov 2025 at 10:06, Josh McKenzie  wrote:

> I think we have had consensus to release every 12 months a few times now.
>
> I think we have too but we never formalized it so end up re-litigating it.
> That kind of re-litigation is a smell to me so I tend to try and push for
> formalization to try and remove wasted effort. I think it's also helpful
> for new contributors coming on board to have guidance around these things
> in one place rather than needing to dig through email archives. And taking
> this from "something we talk about on the dev list and agree with" to
> "something we operationalize and execute on" is still a WIP. :)
>
> I'm w/Mick and I think we could just make it a structured. Something like
> the following:
>
>- Jan 1: cut branch for next major from trunk, release version -beta1
>(or whatever doesn't break our infra)
>   - Stabilize it and GA when CI is green and important bugs are fixed
>- April 1: cut release from trunk as -alpha1
>- July 1: cut release from trunk as -alpha2
>- Oct 1: cut release from trunk as -alpha3
>- Jan 1: GOTO Jan 1 above
>
> So:
>
>1. Train goes out when it's scheduled
>2. Any feature merged throughout the year at worst has a 3 month lag
>between merge and availability in an alpha
>3. Any feature merged throughout the year that is promoted from
>experimental has at most a 12 month lag on availability in a stable GA
>release
>
>
> On Wed, Nov 12, 2025, at 5:17 AM, Mick wrote:
>
> -1 on the SNAPSHOT terminology in any release.  It (by popular use)
> implies mutable artefacts (e.g, hidden timestamped artefacts of the same
> version and unpinned dependencies).   Such a thing can only be a nightly.
> Our codebase also needs adjusting to deal with any qualifier that's not an
> alpha/beta/rc, so if someone is suggesting not using one of those then they
> should also be putting themselves forward to doing that work (meritocracy).
>
> My preference is alpha:  it fits into our existing release lifecycle
> guidelines*, allows cutting releases rather than promotion from nightlies,
> and it works with the code as-is.
>
>
> *) the one item in our release lifecycle guidelines against Alpha that we
> need to relax is: "the system is mostly feature complete”.  My suggestion
> would be to bump that to the beta definition.   I think we should also bump
> "A new branch is created…" from GA down to Beta.
>
> Stefan, we would still go from alpha to beta.  And my understanding is we
> wouldn't necessarily jump to the first beta every 12 months– we still go
> through the lifecycle steps as deemed appropriate.
>
>
>
> > On 12 Nov 2025, at 02:40, Jeremiah Jordan  wrote:
> >
> > Same thoughts as Brandon. I think we have had consensus to release every
> 12 months a few times now. I am happy to continue with that as our North
> Star.
> > Do we want to pick some dates?
> > Maybe cut alpha in January. Optimistically run alphas and betas for 2-3
> months and then GAs would end up in March/April?
> >
> > Happy to cut SNAPSHOT releases through out the rest of the year. As
> suggested by Ekaterina, let’s not call them alpha releases, we already have
> a definition for that name.
> >
> > -Jeremiah
> >
> > On Tue, Nov 11, 2025 at 9:34 AM Brandon Williams 
> wrote:
> > I am +1 to releasing a major every 12 months, but I think we are already
> attempting that, so we should clarify this is a train that leaves at the
> agreed upon date, no exceptions.  I am +1 to cutting alphas as frequently
> as desired, provided they are cut and not promoted from nightly.
> >
> > Kind Regards,
> > Brandon
> >
> >
> > On Tue, Nov 11, 2025 at 9:29 AM Josh McKenzie 
> wrote:
> > Is there anyone who's against releasing a major every 12 months and
> cutting an alpha either once a quarter or month pending release manager
> appetite? Or anyone who's up for making the devil's advocate case against
> 12 months in favor of 18, 24, as-needed based on feature availability, etc?
> >
> > Don't want to confuse silent disapproval vs. silent neutrality. We've
> also had a lot of conversations lately so mindful of that

Re: [DISCUSS] Proposal: formalize release cadence and alphas from trunk

[Josh McKenzie]

> I think we have had consensus to release every 12 months a few times now.
I think we have too but we never formalized it so end up re-litigating it. That 
kind of re-litigation is a smell to me so I tend to try and push for 
formalization to try and remove wasted effort. I think it's also helpful for 
new contributors coming on board to have guidance around these things in one 
place rather than needing to dig through email archives. And taking this from 
"something we talk about on the dev list and agree with" to "something we 
operationalize and execute on" is still a WIP. :)

I'm w/Mick and I think we could just make it a structured pattern. Something 
like the following:
 • Jan 1: cut branch for next major from trunk, release version -beta1 (or 
whatever doesn't break our infra)
   • Stabilize it and GA when CI is green and important bugs are fixed
 • April 1: cut release from trunk as -alpha1
 • July 1: cut release from trunk as -alpha2
 • Oct 1: cut release from trunk as -alpha3
 • Jan 1: GOTO Jan 1 above
So:
 1. Train goes out when it's scheduled
 2. Any feature merged throughout the year at worst has a 3 month lag between 
merge and availability in an alpha
 3. Any feature merged throughout the year that is promoted from experimental 
has at most a 12 month lag on availability in a stable GA release

On Wed, Nov 12, 2025, at 5:17 AM, Mick wrote:
> -1 on the SNAPSHOT terminology in any release.  It (by popular use) implies 
> mutable artefacts (e.g, hidden timestamped artefacts of the same version and 
> unpinned dependencies).   Such a thing can only be a nightly.   Our codebase 
> also needs adjusting to deal with any qualifier that's not an alpha/beta/rc, 
> so if someone is suggesting not using one of those then they should also be 
> putting themselves forward to doing that work (meritocracy).
> 
> My preference is alpha:  it fits into our existing release lifecycle 
> guidelines*, allows cutting releases rather than promotion from nightlies, 
> and it works with the code as-is.
> 
> 
> *) the one item in our release lifecycle guidelines against Alpha that we 
> need to relax is: "the system is mostly feature complete”.  My suggestion 
> would be to bump that to the beta definition.   I think we should also bump 
> "A new branch is created…" from GA down to Beta.
> 
> Stefan, we would still go from alpha to beta.  And my understanding is we 
> wouldn't necessarily jump to the first beta every 12 months– we still go 
> through the lifecycle steps as deemed appropriate.
>  
> 
> 
> > On 12 Nov 2025, at 02:40, Jeremiah Jordan  wrote:
> > 
> > Same thoughts as Brandon. I think we have had consensus to release every 12 
> > months a few times now. I am happy to continue with that as our North Star.
> > Do we want to pick some dates?
> > Maybe cut alpha in January. Optimistically run alphas and betas for 2-3 
> > months and then GAs would end up in March/April?
> > 
> > Happy to cut SNAPSHOT releases through out the rest of the year. As 
> > suggested by Ekaterina, let’s not call them alpha releases, we already have 
> > a definition for that name.
> > 
> > -Jeremiah
> > 
> > On Tue, Nov 11, 2025 at 9:34 AM Brandon Williams  wrote:
> > I am +1 to releasing a major every 12 months, but I think we are already 
> > attempting that, so we should clarify this is a train that leaves at the 
> > agreed upon date, no exceptions.  I am +1 to cutting alphas as frequently 
> > as desired, provided they are cut and not promoted from nightly.
> > 
> > Kind Regards,
> > Brandon
> > 
> > 
> > On Tue, Nov 11, 2025 at 9:29 AM Josh McKenzie  wrote:
> > Is there anyone who's against releasing a major every 12 months and cutting 
> > an alpha either once a quarter or month pending release manager appetite? 
> > Or anyone who's up for making the devil's advocate case against 12 months 
> > in favor of 18, 24, as-needed based on feature availability, etc?
> > 
> > Don't want to confuse silent disapproval vs. silent neutrality. We've also 
> > had a lot of conversations lately so mindful of that; no rush here.
> > 
> > On Mon, Nov 10, 2025, at 5:27 PM, Bernardo Botella wrote:
> >> 
> >> 
> >> +1 on the regular release cadence.
> >> 
> >> I also think there is value in being predictable with releases.
> >> 
> >> Bernardo 
> >> 
> >>> On Nov 9, 2025, at 6:02 PM, Jindal, Himanshu  wrote:
> >>> 
> >>> Thanks for explaining Josh. This makes sense. I am +1 to this proposal.
> >>> 
> >>> Himanshu
> >>> 
> >>> 
> >>> From: Josh McKenzie 
> >>> Date: Saturday, November 8, 2025 at 4:21 AM
> >>> To: dev 
> >>> Subject: RE: [EXTERNAL] [DISCUSS] Proposal: formalize release cadence and 
> >>> alphas from trunk
> >>> CAUTION: This email originated from outside of the organization. Do not 
> >>> click links or open attachments unless you can confirm the sender and 
> >>> know the content is safe.
> >>> 
> >>> I’m trying to understand the goal behind cutting an alpha every three 
> >>> months. Is the intent mainly to catch build issues o

Re: [DISCUSS] Proposal: formalize release cadence and alphas from trunk

[Mick]

-1 on the SNAPSHOT terminology in any release.  It (by popular use) implies 
mutable artefacts (e.g, hidden timestamped artefacts of the same version and 
unpinned dependencies).   Such a thing can only be a nightly.   Our codebase 
also needs adjusting to deal with any qualifier that's not an alpha/beta/rc, so 
if someone is suggesting not using one of those then they should also be 
putting themselves forward to doing that work (meritocracy).

My preference is alpha:  it fits into our existing release lifecycle 
guidelines*, allows cutting releases rather than promotion from nightlies, and 
it works with the code as-is.


*) the one item in our release lifecycle guidelines against Alpha that we need 
to relax is: "the system is mostly feature complete”.  My suggestion would be 
to bump that to the beta definition.   I think we should also bump "A new 
branch is created…" from GA down to Beta.

Stefan, we would still go from alpha to beta.  And my understanding is we 
wouldn't necessarily jump to the first beta every 12 months– we still go 
through the lifecycle steps as deemed appropriate.
 


> On 12 Nov 2025, at 02:40, Jeremiah Jordan  wrote:
> 
> Same thoughts as Brandon. I think we have had consensus to release every 12 
> months a few times now. I am happy to continue with that as our North Star.
> Do we want to pick some dates?
> Maybe cut alpha in January. Optimistically run alphas and betas for 2-3 
> months and then GAs would end up in March/April?
> 
> Happy to cut SNAPSHOT releases through out the rest of the year. As suggested 
> by Ekaterina, let’s not call them alpha releases, we already have a 
> definition for that name.
> 
> -Jeremiah
> 
> On Tue, Nov 11, 2025 at 9:34 AM Brandon Williams  wrote:
> I am +1 to releasing a major every 12 months, but I think we are already 
> attempting that, so we should clarify this is a train that leaves at the 
> agreed upon date, no exceptions.  I am +1 to cutting alphas as frequently as 
> desired, provided they are cut and not promoted from nightly.
> 
> Kind Regards,
> Brandon
> 
> 
> On Tue, Nov 11, 2025 at 9:29 AM Josh McKenzie  wrote:
> Is there anyone who's against releasing a major every 12 months and cutting 
> an alpha either once a quarter or month pending release manager appetite? Or 
> anyone who's up for making the devil's advocate case against 12 months in 
> favor of 18, 24, as-needed based on feature availability, etc?
> 
> Don't want to confuse silent disapproval vs. silent neutrality. We've also 
> had a lot of conversations lately so mindful of that; no rush here.
> 
> On Mon, Nov 10, 2025, at 5:27 PM, Bernardo Botella wrote:
>> 
>> 
>> +1 on the regular release cadence.
>> 
>> I also think there is value in being predictable with releases.
>> 
>> Bernardo 
>> 
>>> On Nov 9, 2025, at 6:02 PM, Jindal, Himanshu  wrote:
>>> 
>>> Thanks for explaining Josh. This makes sense. I am +1 to this proposal.
>>> 
>>> Himanshu
>>> 
>>> 
>>> From: Josh McKenzie 
>>> Date: Saturday, November 8, 2025 at 4:21 AM
>>> To: dev 
>>> Subject: RE: [EXTERNAL] [DISCUSS] Proposal: formalize release cadence and 
>>> alphas from trunk
>>> CAUTION: This email originated from outside of the organization. Do not 
>>> click links or open attachments unless you can confirm the sender and know 
>>> the content is safe.
>>> 
>>> I’m trying to understand the goal behind cutting an alpha every three 
>>> months. Is the intent mainly to catch build issues or bugs earlier than the 
>>> annual release cycle allows?
>>> A few motivations. First, provide a checkpoint for upcoming release 
>>> qualification by users (non-project devs) to work against. It's trivial for 
>>> many of us to just pull a SHA, build it, and have a C* version to roll with 
>>> so pragmatically it doesn't change much on that front for people who are 
>>> hyper plugged in and developing the project. What it does do is implicitly 
>>> focus attention on a certain SHA and artifact for downstream qualification 
>>> work.
>>> 
>>> As a user, if I had a new use-case which required a cluster build-out going 
>>> live in 9 months and knew and trusted a C* major was due in say 7, I would 
>>> grab the latest alpha and just start qualifying against that. Or if I were 
>>> interested in Accord, for instance, I'd be much more inclined to test it 
>>> out if I had an easy way to pull down a release and test it than if I had 
>>> to do the song and dance of building a distribution (again, it's not a lot 
>>> of work IMO but it can be deterring for a user who's not part of the dev 
>>> community).
>>> 
>>> There's also a world in which we have "trunk CI needs to be green since we 
>>> cut a release every 3 months" as a forcing function to focus effort on 
>>> cleaning up our CI and processes more durably. I'm convinced the status quo 
>>> is significantly less efficient for us (constant flaky tests, merges that 
>>> break further tests, slow test proliferation, etc) than were we to focus 
>>> more proactive investme

Re: [DISCUSS] Proposal: formalize release cadence and alphas from trunk

[Miklosovic, Stefan via dev]

Hey,

what happens with beta releases? We will do alpha1 -> alpha4 -> GA? Basically, 
every quarter we do alpha and then we go straight to a major release, no 
beta(s) in between?

From: Josh McKenzie 
Date: Tuesday, 11 November 2025 at 16:27
To: dev 
Subject: Re: [DISCUSS] Proposal: formalize release cadence and alphas from trunk

EXTERNAL EMAIL - USE CAUTION when clicking links or attachments



Is there anyone who's against releasing a major every 12 months and cutting an 
alpha either once a quarter or month pending release manager appetite? Or 
anyone who's up for making the devil's advocate case against 12 months in favor 
of 18, 24, as-needed based on feature availability, etc?

Don't want to confuse silent disapproval vs. silent neutrality. We've also had 
a lot of conversations lately so mindful of that; no rush here.

On Mon, Nov 10, 2025, at 5:27 PM, Bernardo Botella wrote:
+1 on the regular release cadence.

I also think there is value in being predictable with releases.

Bernardo

On Nov 9, 2025, at 6:02 PM, Jindal, Himanshu  wrote:

Thanks for explaining Josh. This makes sense. I am +1 to this proposal.

Himanshu


From: Josh McKenzie 
Date: Saturday, November 8, 2025 at 4:21 AM
To: dev 
Subject: RE: [EXTERNAL] [DISCUSS] Proposal: formalize release cadence and 
alphas from trunk

CAUTION: This email originated from outside of the organization. Do not click 
links or open attachments unless you can confirm the sender and know the 
content is safe.

I’m trying to understand the goal behind cutting an alpha every three months. 
Is the intent mainly to catch build issues or bugs earlier than the annual 
release cycle allows?
A few motivations. First, provide a checkpoint for upcoming release 
qualification by users (non-project devs) to work against. It's trivial for 
many of us to just pull a SHA, build it, and have a C* version to roll with so 
pragmatically it doesn't change much on that front for people who are hyper 
plugged in and developing the project. What it does do is implicitly focus 
attention on a certain SHA and artifact for downstream qualification work.

As a user, if I had a new use-case which required a cluster build-out going 
live in 9 months and knew and trusted a C* major was due in say 7, I would grab 
the latest alpha and just start qualifying against that. Or if I were 
interested in Accord, for instance, I'd be much more inclined to test it out if 
I had an easy way to pull down a release and test it than if I had to do the 
song and dance of building a distribution (again, it's not a lot of work IMO 
but it can be deterring for a user who's not part of the dev community).

There's also a world in which we have "trunk CI needs to be green since we cut 
a release every 3 months" as a forcing function to focus effort on cleaning up 
our CI and processes more durably. I'm convinced the status quo is 
significantly less efficient for us (constant flaky tests, merges that break 
further tests, slow test proliferation, etc) than were we to focus more 
proactive investment in keeping things clean. I plan to discuss that separately 
though.

Some of the value of this earlier use-case qualification is predicated on us 
formalizing our testing and documentation quality bar for new features too; 
just like the "where do we keep CI" aspect of the discussion however I think 
it's worth it to discuss those separately since each topic has nuance and it'll 
take time to build and find our consensus on each topic.

On Sat, Nov 8, 2025, at 4:45 AM, Mick wrote:
+1 on the proposal


> On 7 Nov 2025, at 14:36, Josh McKenzie 
> mailto:jmcken...@apache.org>> wrote:
>
> - These would fall under the "Nightly Builds" area of ASF releases: 
> https://www.apache.org/legal/release-policy.html#what<https://urldefense.com/v3/__https://www.apache.org/legal/release-policy.html*what__;Iw!!Nhn8V6BzJA!XIw2sB2QigOA_InlTTAyAtGTv9O99O1mEgaovz-tOTkbzmCe81IbOcygzp-zXTxw-u8ZjvuqefkuwsuS_Q-tEuuXaw$>.
>  So no publishing them on our site for downloads. I'd advocate for an email 
> to dev@ and user@ to try and drum up some interest. Could give a brief 
> overview of what's in the alpha over the past few months so people would know 
> where to focus testing efforts and exploration.



Anything brought to user@ should then be a formal release not a nightly.
That does not mean a formal release changes any of the limitations that alpha 
imposes, nor that it needs to appear on the downloads page.  The "formal" bit 
on release terminology here is solely about the governance of the release of 
source code at that sha.  It's really nothing to do with QA status of the 
version (but that of course typically aligns to be so in projects).

I propose on that aspect we go through the normal release voting process but 
just not put them on the downloads page, and on user@ refer to them as akin to 
nightlies.

Re: [DISCUSS] Proposal: formalize release cadence and alphas from trunk

[Jeremiah Jordan]

Same thoughts as Brandon. I think we have had consensus to release every 12
months a few times now. I am happy to continue with that as our North Star.
Do we want to pick some dates?
Maybe cut alpha in January. Optimistically run alphas and betas for 2-3
months and then GAs would end up in March/April?

Happy to cut SNAPSHOT releases through out the rest of the year. As
suggested by Ekaterina, let’s not call them alpha releases, we already have
a definition for that name.

-Jeremiah

On Tue, Nov 11, 2025 at 9:34 AM Brandon Williams  wrote:

> I am +1 to releasing a major every 12 months, but I think we are already
> attempting that, so we should clarify this is a train that leaves at the
> agreed upon date, no exceptions.  I am +1 to cutting alphas as frequently
> as desired, provided they are cut and not promoted from nightly.
>
> Kind Regards,
> Brandon
>
>
> On Tue, Nov 11, 2025 at 9:29 AM Josh McKenzie 
> wrote:
>
>> Is there anyone who's against releasing a major every 12 months and
>> cutting an alpha either once a quarter or month pending release manager
>> appetite? Or anyone who's up for making the devil's advocate case against
>> 12 months in favor of 18, 24, as-needed based on feature availability, etc?
>>
>> Don't want to confuse silent disapproval vs. silent neutrality. We've
>> also had a lot of conversations lately so mindful of that; no rush here.
>>
>> On Mon, Nov 10, 2025, at 5:27 PM, Bernardo Botella wrote:
>>
>> +1 on the regular release cadence.
>>
>> I also think there is value in being predictable with releases.
>>
>> Bernardo
>>
>> On Nov 9, 2025, at 6:02 PM, Jindal, Himanshu  wrote:
>>
>> Thanks for explaining Josh. This makes sense. I am +1 to this proposal.
>>
>> Himanshu
>>
>>
>> *From: *Josh McKenzie 
>> *Date: *Saturday, November 8, 2025 at 4:21 AM
>> *To: *dev 
>> *Subject: *RE: [EXTERNAL] [DISCUSS] Proposal: formalize release cadence
>> and alphas from trunk
>>
>> *CAUTION*: This email originated from outside of the organization. Do
>> not click links or open attachments unless you can confirm the sender and
>> know the content is safe.
>>
>> I’m trying to understand the goal behind cutting an alpha every three
>> months. Is the intent mainly to catch build issues or bugs earlier than the
>> annual release cycle allows?
>>
>> A few motivations. First, provide a checkpoint for upcoming release
>> qualification by users (non-project devs) to work against. It's trivial for
>> many of us to just pull a SHA, build it, and have a C* version to roll with
>> so pragmatically it doesn't change much on that front for people who are
>> hyper plugged in and developing the project. What it *does* do is
>> implicitly focus attention on a certain SHA and artifact for downstream
>> qualification work.
>>
>> As a user, if I had a new use-case which required a cluster build-out
>> going live in 9 months and knew and trusted a C* major was due in say 7, I
>> would grab the latest alpha and just start qualifying against that. Or if I
>> were interested in Accord, for instance, I'd be much more inclined to test
>> it out if I had an easy way to pull down a release and test it than if I
>> had to do the song and dance of building a distribution (again, it's not a
>> lot of work IMO but it can be deterring for a user who's not part of the
>> dev community).
>>
>> There's also a world in which we have "trunk CI needs to be green since
>> we cut a release every 3 months" as a forcing function to focus effort on
>> cleaning up our CI and processes more durably. I'm convinced the status quo
>> is significantly less efficient for us (constant flaky tests, merges that
>> break further tests, slow test proliferation, etc) than were we to focus
>> more proactive investment in keeping things clean. I plan to discuss that
>> separately though.
>>
>> Some of the value of this earlier use-case qualification is predicated on
>> us formalizing our testing and documentation quality bar for new features
>> too; just like the "where do we keep CI" aspect of the discussion however I
>> think it's worth it to discuss those separately since each topic has nuance
>> and it'll take time to build and find our consensus on each topic.
>>
>> On Sat, Nov 8, 2025, at 4:45 AM, Mick wrote:
>>
>> +1 on the proposal
>>
>>
>> > On 7 Nov 2025, at 14:36, Josh McKenzie  wrote:
>> >
>> > - These would fall under the "Nightly Builds" area of ASF releases:
>> https://www.apache.org/legal/release-policy.html#what. So no publishing
>> them on our site for downloads. I'd advocate for an email to dev@ and
>> user@ to try and drum up some interest. Could give a brief overview of
>> what's in the alpha over the past few months so people would know where to
>> focus testing efforts and exploration.
>>
>>
>>
>> Anything brought to user@ should then be a formal release not a nightly.
>> That does not mean a formal release changes any of the limitations that
>> alpha imposes, nor that it needs to appear on the downloads page.  The
>> "formal" b

Re: [DISCUSS] Proposal: formalize release cadence and alphas from trunk

[Brandon Williams]

I am +1 to releasing a major every 12 months, but I think we are already
attempting that, so we should clarify this is a train that leaves at the
agreed upon date, no exceptions.  I am +1 to cutting alphas as frequently
as desired, provided they are cut and not promoted from nightly.

Kind Regards,
Brandon


On Tue, Nov 11, 2025 at 9:29 AM Josh McKenzie  wrote:

> Is there anyone who's against releasing a major every 12 months and
> cutting an alpha either once a quarter or month pending release manager
> appetite? Or anyone who's up for making the devil's advocate case against
> 12 months in favor of 18, 24, as-needed based on feature availability, etc?
>
> Don't want to confuse silent disapproval vs. silent neutrality. We've also
> had a lot of conversations lately so mindful of that; no rush here.
>
> On Mon, Nov 10, 2025, at 5:27 PM, Bernardo Botella wrote:
>
> +1 on the regular release cadence.
>
> I also think there is value in being predictable with releases.
>
> Bernardo
>
> On Nov 9, 2025, at 6:02 PM, Jindal, Himanshu  wrote:
>
> Thanks for explaining Josh. This makes sense. I am +1 to this proposal.
>
> Himanshu
>
>
> *From: *Josh McKenzie 
> *Date: *Saturday, November 8, 2025 at 4:21 AM
> *To: *dev 
> *Subject: *RE: [EXTERNAL] [DISCUSS] Proposal: formalize release cadence
> and alphas from trunk
>
> *CAUTION*: This email originated from outside of the organization. Do not
> click links or open attachments unless you can confirm the sender and know
> the content is safe.
>
> I’m trying to understand the goal behind cutting an alpha every three
> months. Is the intent mainly to catch build issues or bugs earlier than the
> annual release cycle allows?
>
> A few motivations. First, provide a checkpoint for upcoming release
> qualification by users (non-project devs) to work against. It's trivial for
> many of us to just pull a SHA, build it, and have a C* version to roll with
> so pragmatically it doesn't change much on that front for people who are
> hyper plugged in and developing the project. What it *does* do is
> implicitly focus attention on a certain SHA and artifact for downstream
> qualification work.
>
> As a user, if I had a new use-case which required a cluster build-out
> going live in 9 months and knew and trusted a C* major was due in say 7, I
> would grab the latest alpha and just start qualifying against that. Or if I
> were interested in Accord, for instance, I'd be much more inclined to test
> it out if I had an easy way to pull down a release and test it than if I
> had to do the song and dance of building a distribution (again, it's not a
> lot of work IMO but it can be deterring for a user who's not part of the
> dev community).
>
> There's also a world in which we have "trunk CI needs to be green since we
> cut a release every 3 months" as a forcing function to focus effort on
> cleaning up our CI and processes more durably. I'm convinced the status quo
> is significantly less efficient for us (constant flaky tests, merges that
> break further tests, slow test proliferation, etc) than were we to focus
> more proactive investment in keeping things clean. I plan to discuss that
> separately though.
>
> Some of the value of this earlier use-case qualification is predicated on
> us formalizing our testing and documentation quality bar for new features
> too; just like the "where do we keep CI" aspect of the discussion however I
> think it's worth it to discuss those separately since each topic has nuance
> and it'll take time to build and find our consensus on each topic.
>
> On Sat, Nov 8, 2025, at 4:45 AM, Mick wrote:
>
> +1 on the proposal
>
>
> > On 7 Nov 2025, at 14:36, Josh McKenzie  wrote:
> >
> > - These would fall under the "Nightly Builds" area of ASF releases:
> https://www.apache.org/legal/release-policy.html#what. So no publishing
> them on our site for downloads. I'd advocate for an email to dev@ and
> user@ to try and drum up some interest. Could give a brief overview of
> what's in the alpha over the past few months so people would know where to
> focus testing efforts and exploration.
>
>
>
> Anything brought to user@ should then be a formal release not a nightly.
> That does not mean a formal release changes any of the limitations that
> alpha imposes, nor that it needs to appear on the downloads page.  The
> "formal" bit on release terminology here is solely about the governance of
> the release of source code at that sha.  It's really nothing to do with QA
> status of the version (but that of course typically aligns to be so in
> projects).
>
> I propose on that aspect we go through the normal release voting process
> but just not put them on the downloads page, and on user@ refer to them
> as akin to nightlies.
>
>
>
>

Re: [DISCUSS] Proposal: formalize release cadence and alphas from trunk

[Josh McKenzie]

Is there anyone who's against releasing a major every 12 months and cutting an 
alpha either once a quarter or month pending release manager appetite? Or 
anyone who's up for making the devil's advocate case against 12 months in favor 
of 18, 24, as-needed based on feature availability, etc?

Don't want to confuse silent disapproval vs. silent neutrality. We've also had 
a lot of conversations lately so mindful of that; no rush here.

On Mon, Nov 10, 2025, at 5:27 PM, Bernardo Botella wrote:
> +1 on the regular release cadence.
> 
> I also think there is value in being predictable with releases.
> 
> Bernardo 
> 
>> On Nov 9, 2025, at 6:02 PM, Jindal, Himanshu  wrote:
>> 
>> Thanks for explaining Josh. This makes sense. I am +1 to this proposal.
>> 
>> Himanshu
>> 
>> 
>> *From: *Josh McKenzie 
>> *Date: *Saturday, November 8, 2025 at 4:21 AM
>> *To: *dev 
>> *Subject: *RE: [EXTERNAL] [DISCUSS] Proposal: formalize release cadence and 
>> alphas from trunk
>> *CAUTION*: This email originated from outside of the organization. Do not 
>> click links or open attachments unless you can confirm the sender and know 
>> the content is safe.
>> 
>> 
>>> I’m trying to understand the goal behind cutting an alpha every three 
>>> months. Is the intent mainly to catch build issues or bugs earlier than the 
>>> annual release cycle allows?
>> A few motivations. First, provide a checkpoint for upcoming release 
>> qualification by users (non-project devs) to work against. It's trivial for 
>> many of us to just pull a SHA, build it, and have a C* version to roll with 
>> so pragmatically it doesn't change much on that front for people who are 
>> hyper plugged in and developing the project. What it *does* do is implicitly 
>> focus attention on a certain SHA and artifact for downstream qualification 
>> work.
>> 
>> As a user, if I had a new use-case which required a cluster build-out going 
>> live in 9 months and knew and trusted a C* major was due in say 7, I would 
>> grab the latest alpha and just start qualifying against that. Or if I were 
>> interested in Accord, for instance, I'd be much more inclined to test it out 
>> if I had an easy way to pull down a release and test it than if I had to do 
>> the song and dance of building a distribution (again, it's not a lot of work 
>> IMO but it can be deterring for a user who's not part of the dev community).
>> 
>> There's also a world in which we have "trunk CI needs to be green since we 
>> cut a release every 3 months" as a forcing function to focus effort on 
>> cleaning up our CI and processes more durably. I'm convinced the status quo 
>> is significantly less efficient for us (constant flaky tests, merges that 
>> break further tests, slow test proliferation, etc) than were we to focus 
>> more proactive investment in keeping things clean. I plan to discuss that 
>> separately though.
>> 
>> Some of the value of this earlier use-case qualification is predicated on us 
>> formalizing our testing and documentation quality bar for new features too; 
>> just like the "where do we keep CI" aspect of the discussion however I think 
>> it's worth it to discuss those separately since each topic has nuance and 
>> it'll take time to build and find our consensus on each topic.
>> 
>> On Sat, Nov 8, 2025, at 4:45 AM, Mick wrote:
>>> +1 on the proposal
>>> 
>>> 
>>> > On 7 Nov 2025, at 14:36, Josh McKenzie  wrote:
>>> > 
>>> > - These would fall under the "Nightly Builds" area of ASF releases: 
>>> > https://www.apache.org/legal/release-policy.html#what. So no publishing 
>>> > them on our site for downloads. I'd advocate for an email to dev@ and 
>>> > user@ to try and drum up some interest. Could give a brief overview of 
>>> > what's in the alpha over the past few months so people would know where 
>>> > to focus testing efforts and exploration.
>>> 
>>> 
>>> 
>>> Anything brought to user@ should then be a formal release not a nightly. 
>>> That does not mean a formal release changes any of the limitations that 
>>> alpha imposes, nor that it needs to appear on the downloads page.  The 
>>> "formal" bit on release terminology here is solely about the governance of 
>>> the release of source code at that sha.  It's really nothing to do with QA 
>>> status of the version (but that of course typically aligns to be so in 
>>> projects).
>>> 
>>> I propose on that aspect we go through the normal release voting process 
>>> but just not put them on the downloads page, and on user@ refer to them as 
>>> akin to nightlies.
>> 

Re: [DISCUSS] Proposal: formalize release cadence and alphas from trunk

[Bernardo Botella]

+1 on the regular release cadence.

I also think there is value in being predictable with releases.

Bernardo 

> On Nov 9, 2025, at 6:02 PM, Jindal, Himanshu  wrote:
> 
> Thanks for explaining Josh. This makes sense. I am +1 to this proposal.
> 
> Himanshu
> 
> From: Josh McKenzie 
> Date: Saturday, November 8, 2025 at 4:21 AM
> To: dev 
> Subject: RE: [EXTERNAL] [DISCUSS] Proposal: formalize release cadence and 
> alphas from trunk
> 
> CAUTION: This email originated from outside of the organization. Do not click 
> links or open attachments unless you can confirm the sender and know the 
> content is safe.
> 
> 
> I’m trying to understand the goal behind cutting an alpha every three months. 
> Is the intent mainly to catch build issues or bugs earlier than the annual 
> release cycle allows?
> A few motivations. First, provide a checkpoint for upcoming release 
> qualification by users (non-project devs) to work against. It's trivial for 
> many of us to just pull a SHA, build it, and have a C* version to roll with 
> so pragmatically it doesn't change much on that front for people who are 
> hyper plugged in and developing the project. What it does do is implicitly 
> focus attention on a certain SHA and artifact for downstream qualification 
> work.
> 
> As a user, if I had a new use-case which required a cluster build-out going 
> live in 9 months and knew and trusted a C* major was due in say 7, I would 
> grab the latest alpha and just start qualifying against that. Or if I were 
> interested in Accord, for instance, I'd be much more inclined to test it out 
> if I had an easy way to pull down a release and test it than if I had to do 
> the song and dance of building a distribution (again, it's not a lot of work 
> IMO but it can be deterring for a user who's not part of the dev community).
> 
> There's also a world in which we have "trunk CI needs to be green since we 
> cut a release every 3 months" as a forcing function to focus effort on 
> cleaning up our CI and processes more durably. I'm convinced the status quo 
> is significantly less efficient for us (constant flaky tests, merges that 
> break further tests, slow test proliferation, etc) than were we to focus more 
> proactive investment in keeping things clean. I plan to discuss that 
> separately though.
> 
> Some of the value of this earlier use-case qualification is predicated on us 
> formalizing our testing and documentation quality bar for new features too; 
> just like the "where do we keep CI" aspect of the discussion however I think 
> it's worth it to discuss those separately since each topic has nuance and 
> it'll take time to build and find our consensus on each topic.
> 
> On Sat, Nov 8, 2025, at 4:45 AM, Mick wrote:
> +1 on the proposal
> 
> 
> > On 7 Nov 2025, at 14:36, Josh McKenzie  > > wrote:
> > 
> > - These would fall under the "Nightly Builds" area of ASF releases: 
> > https://www.apache.org/legal/release-policy.html#what. So no publishing 
> > them on our site for downloads. I'd advocate for an email to dev@ and user@ 
> > to try and drum up some interest. Could give a brief overview of what's in 
> > the alpha over the past few months so people would know where to focus 
> > testing efforts and exploration.
> 
> 
> 
> Anything brought to user@ should then be a formal release not a nightly. 
> That does not mean a formal release changes any of the limitations that alpha 
> imposes, nor that it needs to appear on the downloads page.  The "formal" bit 
> on release terminology here is solely about the governance of the release of 
> source code at that sha.  It's really nothing to do with QA status of the 
> version (but that of course typically aligns to be so in projects).
> 
> I propose on that aspect we go through the normal release voting process but 
> just not put them on the downloads page, and on user@ refer to them as akin 
> to nightlies.
> 

Re: [DISCUSS] Proposal: formalize release cadence and alphas from trunk

[Jindal, Himanshu]

Thanks for explaining Josh. This makes sense. I am +1 to this proposal.

Himanshu

From: Josh McKenzie 
Date: Saturday, November 8, 2025 at 4:21 AM
To: dev 
Subject: RE: [EXTERNAL] [DISCUSS] Proposal: formalize release cadence and 
alphas from trunk


CAUTION: This email originated from outside of the organization. Do not click 
links or open attachments unless you can confirm the sender and know the 
content is safe.

I’m trying to understand the goal behind cutting an alpha every three months. 
Is the intent mainly to catch build issues or bugs earlier than the annual 
release cycle allows?
A few motivations. First, provide a checkpoint for upcoming release 
qualification by users (non-project devs) to work against. It's trivial for 
many of us to just pull a SHA, build it, and have a C* version to roll with so 
pragmatically it doesn't change much on that front for people who are hyper 
plugged in and developing the project. What it does do is implicitly focus 
attention on a certain SHA and artifact for downstream qualification work.

As a user, if I had a new use-case which required a cluster build-out going 
live in 9 months and knew and trusted a C* major was due in say 7, I would grab 
the latest alpha and just start qualifying against that. Or if I were 
interested in Accord, for instance, I'd be much more inclined to test it out if 
I had an easy way to pull down a release and test it than if I had to do the 
song and dance of building a distribution (again, it's not a lot of work IMO 
but it can be deterring for a user who's not part of the dev community).

There's also a world in which we have "trunk CI needs to be green since we cut 
a release every 3 months" as a forcing function to focus effort on cleaning up 
our CI and processes more durably. I'm convinced the status quo is 
significantly less efficient for us (constant flaky tests, merges that break 
further tests, slow test proliferation, etc) than were we to focus more 
proactive investment in keeping things clean. I plan to discuss that separately 
though.

Some of the value of this earlier use-case qualification is predicated on us 
formalizing our testing and documentation quality bar for new features too; 
just like the "where do we keep CI" aspect of the discussion however I think 
it's worth it to discuss those separately since each topic has nuance and it'll 
take time to build and find our consensus on each topic.

On Sat, Nov 8, 2025, at 4:45 AM, Mick wrote:
+1 on the proposal


> On 7 Nov 2025, at 14:36, Josh McKenzie 
> mailto:jmcken...@apache.org>> wrote:
>
> - These would fall under the "Nightly Builds" area of ASF releases: 
> https://www.apache.org/legal/release-policy.html#what. So no publishing them 
> on our site for downloads. I'd advocate for an email to dev@ and user@ to try 
> and drum up some interest. Could give a brief overview of what's in the alpha 
> over the past few months so people would know where to focus testing efforts 
> and exploration.



Anything brought to user@ should then be a formal release not a nightly.
That does not mean a formal release changes any of the limitations that alpha 
imposes, nor that it needs to appear on the downloads page.  The "formal" bit 
on release terminology here is solely about the governance of the release of 
source code at that sha.  It's really nothing to do with QA status of the 
version (but that of course typically aligns to be so in projects).

I propose on that aspect we go through the normal release voting process but 
just not put them on the downloads page, and on user@ refer to them as akin to 
nightlies.

Re: [DISCUSS] Proposal: formalize release cadence and alphas from trunk

[Ekaterina Dimitrova]

Thanks, Josh. Overall I am *+1 to this proposal* and thank you for
starting/driving this important discussion.

It also aligns with the question I raised on the backport branch discussion
thread: "I am wondering, what is the signal of having the need for such a
branch? Our current release cycle needs revision? (Of course, that is an
independent activity of what we discuss here)."

My only question is the naming: are we certain we want to call these
quarterly releases *'alpha'*?
Given how we define and document our official release stages, particularly
alpha releases, here:
https://cwiki.apache.org/confluence/display/CASSANDRA/Release+Lifecycle
If the goal is to produce a stable-enough-to-test artifact from a
releasable trunk (with unstable features disabled behind a feature flag)
and that artifact goes through a *vote* and is *advertised* (even if only
on the dev list), then it *should be an official Alpha release* (e.g., Alpha
1, 2, 3, 4). This would set clear expectations and predictability (we know
there are at least four alphas per year).

However, if these artifacts are* voted upon* but *not advertised on the
user list*, calling them 'alpha' could be confusing and misleading to the
community compared to our documented lifecycle. In that case, a different
term like *'snapshot'* might be better suited? If we keep those being
called alpha, how do we call an officially advertised alpha (on @dev and
Downloads page)? What do others think?

Best regards,
Ekaterina

Re: [DISCUSS] Proposal: formalize release cadence and alphas from trunk

[Josh McKenzie]

> I’m trying to understand the goal behind cutting an alpha every three months. 
> Is the intent mainly to catch build issues or bugs earlier than the annual 
> release cycle allows?
A few motivations. First, provide a checkpoint for upcoming release 
qualification by users (non-project devs) to work against. It's trivial for 
many of us to just pull a SHA, build it, and have a C* version to roll with so 
pragmatically it doesn't change much on that front for people who are hyper 
plugged in and developing the project. What it *does* do is implicitly focus 
attention on a certain SHA and artifact for downstream qualification work.

As a user, if I had a new use-case which required a cluster build-out going 
live in 9 months and knew and trusted a C* major was due in say 7, I would grab 
the latest alpha and just start qualifying against that. Or if I were 
interested in Accord, for instance, I'd be much more inclined to test it out if 
I had an easy way to pull down a release and test it than if I had to do the 
song and dance of building a distribution (again, it's not a lot of work IMO 
but it can be deterring for a user who's not part of the dev community).

There's also a world in which we have "trunk CI needs to be green since we cut 
a release every 3 months" as a forcing function to focus effort on cleaning up 
our CI and processes more durably. I'm convinced the status quo is 
significantly less efficient for us (constant flaky tests, merges that break 
further tests, slow test proliferation, etc) than were we to focus more 
proactive investment in keeping things clean. I plan to discuss that separately 
though.

Some of the value of this earlier use-case qualification is predicated on us 
formalizing our testing and documentation quality bar for new features too; 
just like the "where do we keep CI" aspect of the discussion however I think 
it's worth it to discuss those separately since each topic has nuance and it'll 
take time to build and find our consensus on each topic.

On Sat, Nov 8, 2025, at 4:45 AM, Mick wrote:
> +1 on the proposal
> 
> 
> > On 7 Nov 2025, at 14:36, Josh McKenzie  wrote:
> > 
> > - These would fall under the "Nightly Builds" area of ASF releases: 
> > https://www.apache.org/legal/release-policy.html#what. So no publishing 
> > them on our site for downloads. I'd advocate for an email to dev@ and user@ 
> > to try and drum up some interest. Could give a brief overview of what's in 
> > the alpha over the past few months so people would know where to focus 
> > testing efforts and exploration.
> 
> 
> 
> Anything brought to user@ should then be a formal release not a nightly. 
> That does not mean a formal release changes any of the limitations that alpha 
> imposes, nor that it needs to appear on the downloads page.  The "formal" bit 
> on release terminology here is solely about the governance of the release of 
> source code at that sha.  It's really nothing to do with QA status of the 
> version (but that of course typically aligns to be so in projects).
> 
> I propose on that aspect we go through the normal release voting process but 
> just not put them on the downloads page, and on user@ refer to them as akin 
> to nightlies.

Re: [DISCUSS] Proposal: formalize release cadence and alphas from trunk

[Mick]

+1 on the proposal


> On 7 Nov 2025, at 14:36, Josh McKenzie  wrote:
> 
> - These would fall under the "Nightly Builds" area of ASF releases: 
> https://www.apache.org/legal/release-policy.html#what. So no publishing them 
> on our site for downloads. I'd advocate for an email to dev@ and user@ to try 
> and drum up some interest. Could give a brief overview of what's in the alpha 
> over the past few months so people would know where to focus testing efforts 
> and exploration.



Anything brought to user@ should then be a formal release not a nightly. 
That does not mean a formal release changes any of the limitations that alpha 
imposes, nor that it needs to appear on the downloads page.  The "formal" bit 
on release terminology here is solely about the governance of the release of 
source code at that sha.  It's really nothing to do with QA status of the 
version (but that of course typically aligns to be so in projects).

I propose on that aspect we go through the normal release voting process but 
just not put them on the downloads page, and on user@ refer to them as akin to 
nightlies.

Re: [DISCUSS] Proposal: formalize release cadence and alphas from trunk

[Jindal, Himanshu]

Hi Josh,

Thanks for kicking this off. I’m a  +1 on moving toward a more frequent release 
cadence — smaller, faster releases reduce risk and help maintain momentum in 
the community. I’m also +1 on the points you outlined here: 
https://lists.apache.org/thread/v91jyjsxpqlv570h2lp8cnhnk5cht7sr

One question on the alpha proposal — I’m trying to understand the goal behind 
cutting an alpha every three months. Is the intent mainly to catch build issues 
or bugs earlier than the annual release cycle allows?

Best,
Himanshu

From: Josh McKenzie 
Date: Friday, November 7, 2025 at 5:40 AM
To: dev 
Subject: [EXTERNAL] [DISCUSS] Proposal: formalize release cadence and alphas 
from trunk


CAUTION: This email originated from outside of the organization. Do not click 
links or open attachments unless you can confirm the sender and know the 
content is safe.

Byproduct of our discussion about backport motivations: 
https://lists.apache.org/thread/5nv1f4bng4nw5ofgh135k5pf2f6l6lgl

Regardless of how the above does or doesn't continue to evolve, I'd like to 
propose the following directional goal for release cadence on the project 
(language to be refined if we want to move forward with formalizing the idea in 
any kind of voted on process). I'd like us to document this in the wiki if 
there's consensus on it.

We cut a yearly MAJOR release from trunk (calendar-based release train model)
- Pick an end of quarter we will release on and rewind 3 months to a freeze
- April 1, July 1, October 1, Jan 1?

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.

We cut an alpha from trunk every [MONTH|QUARTER].
- If quarterly, alphas are cut April 1, July 1, Oct 1, Jan 1 representing 3 
months of combined commits each
- Version as MAJOR.0.0-alpha

Alpha support policy:
- None. We don't backport fixes to them, they're not part of the merge path. 
They're just a tag on a given date we confirm builds and we package and vote on 
it.
- These would fall under the "Nightly Builds" area of ASF releases: 
https://www.apache.org/legal/release-policy.html#what. So no publishing them on 
our site for downloads. I'd advocate for an email to dev@ and user@ to try and 
drum up some interest. Could give a brief overview of what's in the alpha over 
the past few months so people would know where to focus testing efforts and 
exploration.

---
Do we consensus on regular yearly releases from trunk being the right cadence?
Do we consensus on cutting alphas being useful for getting focus concentrated 
on qualifying nearer trunk? Incremental qualification labor and effort?