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 <[email protected]> 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 <[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. >> >>> >> > >> >> >> >> >>
