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