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