Should OpenDAL adopt a weekly release cadence?

[Xuanwo]

Should OpenDAL adopt a weekly release cadence?

I'd like to discuss whether OpenDAL should prepare a release candidate every week, and whether the following workflow would make that sustainable for release managers and reviewers.

The goal is to make merged improvements available on a predictable schedule while reducing repetitive release work. A weekly cadence would still depend on maintainers having time to verify artifacts and vote, including over the weekend.

Proposed cadence

• Cut a candidate from main every Friday at 00:00 UTC. Skip weeks with no changes to release.
• Build and verify the candidate, then ask a release manager to sign and upload it.
• Keep the release vote open for at least 72 hours from the actual vote announcement. Monday availability is a target, not a deadline that overrides release requirements.
• If a candidate fails or is withdrawn, prepare the next candidate from the next week's head and recalculate versions. If a vote is still pending, finish or explicitly withdraw it before starting another candidate.

Proposed workflow

Stage	GitHub Actions	Maintainers and voters
Prepare	Freeze the cutoff commit, calculate versions and changelog, and create a candidate branch.	Review compatibility and release-impact declarations during normal PR review.
Build	Build the source packages, run verification and language CI, and prepare Maven staging and a report.	Investigate failures; fixes go through normal PRs to main.
Sign and stage	Provide the frozen artifacts and exact vote text; verify uploaded signatures and staged files.	Run just release-sign <candidate> --key <fingerprint>, review the report and vote text, sign with GPG, and upload to ASF SVN using local credentials.
Verify and vote	Open the reviewed vote and track its status.	Run just release-verify <candidate>, review the source, licenses and test results, and cast an independent vote. Signing does not count as a vote.
Approve the result	Present the vote tally and proposed result, release notes and announcement. Recheck the candidate before proceeding.	Review all votes and unresolved concerns, including mail-only votes, then approve the result in a protected environment.
Publish	Post the approved result, verify source promotion, publish the language packages and release pages, and send the approved announcement.	Run just release-promote <candidate> locally to move the approved sources from ASF dist/dev to dist/release.
Synchronize	Prepare a mechanical version-sync PR against the latest main.	Review that PR through the normal repository process.

SVN credentials stay on the maintainer's machine. Actions reads back the uploaded files to verify them; it does not need an ASF SVN write account. An interrupted source upload can be retried with just release-upload <candidate> without rebuilding or signing again.

Versions and failed candidates

Candidate branches contain the version and changelog updates. After a successful release, a separate PR synchronizes those changes onto the latest main; we do not merge the whole candidate branch.

The next release is calculated from the last successful official release and accumulated changes, rather than from a failed candidate or whether the synchronization PR has merged. A failed 0.59.1-rc.1 could therefore be followed by 0.59.1-rc.2, or by 0.60.0-rc.1 if new changes require a minor bump.

An initial implementation could use the existing complete package matrix: when there are releasable changes, each package gets at least a patch increment, with larger increments where required. This is simpler to operate, but it also creates releases for unchanged packages. Feedback on that tradeoff would be useful.

Once official publication has started, a failure in one channel must be recovered using the same approved candidate. It cannot be replaced with a new head while other channels already contain the release.

Try it with an RC dry run first

Before enabling a weekly schedule, we could exercise the actual RC preparation, builds, signing, SVN dev upload, verification, and an explicitly labeled rehearsal vote. The normal vote checks would remain in place.

The final approval would end the rehearsal without promoting sources, pushing a stable tag, publishing stable packages, sending an announcement, or advancing the official version baseline. RC tags, dev artifacts and closed Maven staging repositories could remain for later cleanup. This would test the pre-release handoffs without making an official release; production publication would still need verification on the first real release.

A local implementation prototype exists, with AI assistance in the design, code and this draft. It is disabled by default and has not been exercised end to end against the live release services. Community agreement and deployment validation are still needed.

Questions for the community

1. Would a weekly release cadence be useful, and can we sustain the verification and voting effort?
2. Is Friday cutoff with a Monday target a reasonable schedule, or would another day work better for reviewers?
3. Does this division of work between Actions, the release manager and voters look practical? What steps or failure cases are missing?
4. Should we start with the complete package matrix, or require selective package releases before adopting this cadence?

[github-actions[bot]]

Mailing list thread: https://lists.apache.org/thread/9xjfmgoq6jy1pxnkvpgdlkdlnp5kn5y9

[tisonkun]

I like this idea and I actually consider something similar to other ASF projects I work on (datasketches-rust, asyncband) these days :D

[dave2wave]

Do you have reproducible builds?

If so you can build and sign in CI.

If not then the Release Manager must build and sign using their own hardware.

Every committer can be a Release Manager. Using the new Apache Trusted Releases (ATR) all PMC members automatically are and committers may be designated. ATR access requires 2FA login. For CI uploads there is a GHA. For RMs there are multiple methods to upload including SVN, Python client, rsync, browser, and Maven.

[Xuanwo]

We do! 🤩

To move forward, maybe we should start with create an automated signing & SVn account?

[Xuanwo]

Ok, we already have Service RM GPG key, we can just move!