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 <[email protected]> > 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 <[email protected] > <mailto:[email protected]>> 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 <[email protected] >> <mailto:[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] >>> <mailto:[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] >>>>> <mailto:[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] >>>>> <mailto:[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: >>>>> Train goes out when it's scheduled >>>>> Any feature merged throughout the year at worst has a 3 month lag between >>>>> merge and availability in an alpha >>>>> 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] >>>>>> > <mailto:[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] >>>>>> > <mailto:[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] >>>>>> > <mailto:[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] >>>>>> >>> <mailto:[email protected]>> wrote: >>>>>> >>> >>>>>> >>> Thanks for explaining Josh. This makes sense. I am +1 to this >>>>>> >>> proposal. >>>>>> >>> >>>>>> >>> Himanshu >>>>>> >>> >>>>>> >>> >>>>>> >>> From: Josh McKenzie <[email protected] >>>>>> >>> <mailto:[email protected]>> >>>>>> >>> Date: Saturday, November 8, 2025 at 4:21 AM >>>>>> >>> To: dev <[email protected] <mailto:[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] >>>>>> >>> > <mailto:[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. >>>>>> >>> >>>>>> > >>>>>> >>>>>> >>>>> >>>>
