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