> 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. >>>> >>> >>>> > >>>> >>>> >>>
