> I think we have had consensus to release every 12 months a few times now. I think we have too but we never formalized it so end up re-litigating it. That kind of re-litigation is a smell to me so I tend to try and push for formalization to try and remove wasted effort. I think it's also helpful for new contributors coming on board to have guidance around these things in one place rather than needing to dig through email archives. And taking this from "something we talk about on the dev list and agree with" to "something we operationalize and execute on" is still a WIP. :)
I'm w/Mick and I think we could just make it a structured pattern. Something like the following: • Jan 1: cut branch for next major from trunk, release version -beta1 (or whatever doesn't break our infra) • Stabilize it and GA when CI is green and important bugs are fixed • April 1: cut release from trunk as -alpha1 • July 1: cut release from trunk as -alpha2 • Oct 1: cut release from trunk as -alpha3 • Jan 1: GOTO Jan 1 above So: 1. Train goes out when it's scheduled 2. Any feature merged throughout the year at worst has a 3 month lag between merge and availability in an alpha 3. Any feature merged throughout the year that is promoted from experimental has at most a 12 month lag on availability in a stable GA release On Wed, Nov 12, 2025, at 5:17 AM, Mick wrote: > -1 on the SNAPSHOT terminology in any release. It (by popular use) implies > mutable artefacts (e.g, hidden timestamped artefacts of the same version and > unpinned dependencies). Such a thing can only be a nightly. Our codebase > also needs adjusting to deal with any qualifier that's not an alpha/beta/rc, > so if someone is suggesting not using one of those then they should also be > putting themselves forward to doing that work (meritocracy). > > My preference is alpha: it fits into our existing release lifecycle > guidelines*, allows cutting releases rather than promotion from nightlies, > and it works with the code as-is. > > > *) the one item in our release lifecycle guidelines against Alpha that we > need to relax is: "the system is mostly feature complete”. My suggestion > would be to bump that to the beta definition. I think we should also bump > "A new branch is created…" from GA down to Beta. > > Stefan, we would still go from alpha to beta. And my understanding is we > wouldn't necessarily jump to the first beta every 12 months– we still go > through the lifecycle steps as deemed appropriate. > > > > > On 12 Nov 2025, at 02:40, Jeremiah Jordan <[email protected]> wrote: > > > > 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. > >>> > > > >
