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