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