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