Hi Josh, Thanks for kicking this off. I’m a +1 on moving toward a more frequent release cadence — smaller, faster releases reduce risk and help maintain momentum in the community. I’m also +1 on the points you outlined here: https://lists.apache.org/thread/v91jyjsxpqlv570h2lp8cnhnk5cht7sr
One question on the alpha proposal — 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? Best, Himanshu From: Josh McKenzie <[email protected]> Date: Friday, November 7, 2025 at 5:40 AM To: dev <[email protected]> Subject: [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. Byproduct of our discussion about backport motivations: https://lists.apache.org/thread/5nv1f4bng4nw5ofgh135k5pf2f6l6lgl Regardless of how the above does or doesn't continue to evolve, I'd like to propose the following directional goal for release cadence on the project (language to be refined if we want to move forward with formalizing the idea in any kind of voted on process). I'd like us to document this in the wiki if there's consensus on it. We cut a yearly MAJOR release from trunk (calendar-based release train model) - Pick an end of quarter we will release on and rewind 3 months to a freeze - April 1, July 1, October 1, Jan 1? We reserve the right to release more frequently than this if we decide to - MAJOR.MINOR? Would keep oldest GA for a predictable length with support model but introduce a new branch into our merge-path which is extra merge and CI toil. - Or new MAJOR and we drop oldest supported? If we cut alphas (see below), the pressure for out-of-cycle releases to make features available may be mitigated. We cut an alpha from trunk every [MONTH|QUARTER]. - If quarterly, alphas are cut April 1, July 1, Oct 1, Jan 1 representing 3 months of combined commits each - Version as MAJOR.0.0-alpha Alpha support policy: - None. We don't backport fixes to them, they're not part of the merge path. They're just a tag on a given date we confirm builds and we package and vote on it. - 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. --- Do we consensus on regular yearly releases from trunk being the right cadence? Do we consensus on cutting alphas being useful for getting focus concentrated on qualifying nearer trunk? Incremental qualification labor and effort?
