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