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 <[email protected]> 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 <[email protected]> > 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 <[email protected]> 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 <[email protected]> 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 <[email protected]> > 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 <[email protected]> > 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 <[email protected]> > wrote: > >>> > >>> Thanks for explaining Josh. This makes sense. I am +1 to this proposal. > >>> > >>> Himanshu > >>> > >>> > >>> From: Josh McKenzie <[email protected]> > >>> Date: Saturday, November 8, 2025 at 4:21 AM > >>> To: dev <[email protected]> > >>> 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 <[email protected]> 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. > >>> > > > > > > >
