Release Cadence Improvement Proposal

[zhouyuan]

Problem

Gluten ships formal releases quarterly (~3 months apart). For a fast-moving project this means users wait
a long time to try new features without building from source.

What Already Exists

Gluten publishes pre-built nightly bundle JARs at https://nightlies.apache.org/gluten/:

Directory	JDK	Spark versions	Architectures
nightly-release-jdk8/	8	3.4, 3.5, 4.0, 4.1	x86_64, aarch64
nightly-release-jdk17/	17	3.4, 3.5, 4.0, 4.1	x86_64, aarch64
nightly-release-jdk21/	21	3.4, 3.5, 4.0, 4.1	x86_64, aarch64
nightly-release-jdk17-enhanced/	17	3.4, 3.5, 4.0, 4.1	x86_64, aarch64

These are not official ASF releases. They carry Apache's standard nightly disclaimer and should not be
used in production.

The main limitation is that most users don't know the server exists.

Proposed Strategy for Gluten

Tier 1 — Promote the nightly server (zero code change)

• Add a "Nightly Builds" section to the website and README.md linking
  https://nightlies.apache.org/gluten/ with a clear "not official releases" disclaimer.
• Remove stale SNAPSHOT JARs from previous release cycles (1.5.0, 1.6.0, 1.7.0 currently accumulate).

Tier 2 — Monthly minor releases with a release-branch model

Compress the cadence from quarterly to monthly (or every 6 weeks) by adopting a release-branch
workflow:

1. Week 0 — Cut branch-1.8 from main. Pin the Velox fork commit. main moves on to 1.9.0.
2. Week 1 — Audit the branch for regressions (benchmarks, CI health, operator coverage).
3. Weeks 2–3 — Fix regressions on main and backport them to branch-1.8.
4. Week 4 — Remove -SNAPSHOT, generate changelog, tag v1.8.0-rc0, open 72-hour vote.
5. Week 5 — On vote pass, promote artifacts, publish Maven release, announce.

Tier 3 — Patch releases (as needed)

Backport critical fixes (security, data correctness, crash) to the latest release branch and release as
1.8.1 without waiting for the next cycle. Same 72-hour RC vote; no new branch required.

Adoption Roadmap

Phase	What	When
1	Promote nightly server in docs/README; clean up stale JARs	Before 1.8.0
2	Adopt release-branch workflow for 1.8.0; keep quarterly cadence while practicing it	1.8.0 cycle
3	Compress to monthly cadence; introduce Release Manager rotation	1.9.0 or later

Work Required

Area	Change	Effort
Docs / README	Add nightly server link; clean up old JARs	Low
Release scripts	Make build-release.sh runnable on a branch (not just a tag)	Medium
.asf.yaml	Add branch-X.Y to protected_branches	Low
HowToRelease.md	Document release-branch model and backport labels	Medium
Process	Introduce rotating Release Manager role	Process

[philo-he]

Thanks for bringing up this topic.

Week 4 — Remove -SNAPSHOT, generate changelog, tag v1.8.0-rc0, open a 72-hour vote.
Week 5 — On vote pass, promote artifacts, publish the Maven release, and announce.

Based on our previous experience, we may need two or three release candidates (RCs), each requiring verification and another round of voting. It would be helpful to allow some flexibility in the timeline for these additional rounds.

A faster release cadence would certainly help users benefit from new features and fixes sooner. However, even with more automation, release preparation, verification, and coordination still require manual effort. A four-week cadence would mean approximately 13 minor releases per year, so we should also consider the maintenance effort, including investigating release-specific issues and supporting users on maintained versions.

With these considerations in mind, could we start with a target of six to eight weeks as an experiment? After a few release cycles, we could review the verification effort, maintenance workload, and community feedback, then adjust the cadence to a pace we can sustainably support.

[weiting-chen]

Thanks, this is a helpful suggestion. I agree that a six-to-eight-week experimental target is more realistic than committing immediately to a fixed monthly cadence. Recent Gluten releases often needed multiple RCs, and each RC requires another verification and voting round. The proposal should therefore include schedule contingency and treat the cadence as a target that may slip when release-readiness gates are not met.

It would also be useful to review the experiment after a few cycles using RC count, verification effort, RM/reviewer workload, maintenance and user-support cost, CI stability, and community feedback.

I still see a few items to address before adoption:

• The website/README should not promote nightly downloads to general users, even with a disclaimer; ASF policy directs public users to official releases. Nightlies can remain available through development-community channels.
• Define maintained branches, EOL, backport eligibility, security handling, and required branch qualification.
• Pin the exact Velox commit at branch cut and automate artifact provenance plus LICENSE/NOTICE validation.
• Qualify the exact packaged RC, since the current release build skips tests.
• Treat Spark main as a pinned CI compatibility canary, not a supported public release target. A Spark profile being buildable does not by itself establish support.

Overall, I support rehearsing the branch model for 1.8 and then piloting the proposed six-to-eight-week cadence. This gives the community useful evidence without making quality, voting, or maintenance commitments depend on a fixed calendar.