GitHub user Xuanwo created a discussion: Should OpenDAL adopt a weekly release cadence?
# 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 Asia/Shanghai (Thursday 16: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 link: https://github.com/apache/opendal/discussions/8231 ---- This is an automatically sent email for [email protected]. To unsubscribe, please send an email to: [email protected]
