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