[NEW] Low-Touch Releases for Valkey OSS
Low-Touch Releases for Valkey OSS
Valkey has automated most of the post-release tasks, but not the release itself. Pre-release work is still staggered, and post-release work starts across multiple repositories, but it is not followed to completion. A maintainer still connects all these parts together.
The current release procedure reflects this fragmentation, and is somewhat outdated. The proposal makes a Valkey release one coordinated, automated operation.
What fails today?
A maintainer merges the notes pull request and creates a GitHub Release from a selected branch. Valkey sends only the version and environment to valkey-release-automation, which publishes artifacts and starts downstream work. Helm is separate. A dispatch or opened pull request counts as success while the public result may still be pending or broken.
Recent releases exposed the following gaps
| Incident |
|---|
8.0.8 targeted unstable and was revoked. We had a similar issue in 8.1.9 as well, but it was caught early |
9.1.1 candidate CI failed, but the same commit was published |
7.2.14 was published before all 40 stable-package builds failed |
Patch documentation required a manually created tag; the 9.1.1 man-page build and a later documentation-to-website dispatch failed outside the release run |
The 9.1.1 container and website updates were tracked only in their respective repositories |
Bundle 8.1.9 started before its required Valkey base image was public |
The 9.1.1 Helm update was opened manually the following day |
These incidents were repaired individually. The release system neither prevented them nor presented their combined state
Proposed Release Experience
valkey-ci-agent acts as the release controller and observer. An issue in Valkey is the durable release record.
For a 9.2.0 GA release:
- An authorized release owner runs Start release with branch
9.2, intentGA, and release-note urgency. The workflow validates the owner and branch. - Only one release may be active per release branch; different branches may proceed concurrently. The controller derives
9.2.0and opens Release 9.2.0 in Valkey. A second9.2request is rejected and linked to the active issue. - The existing notes automation opens the version-and-notes pull request. A maintainer reviews and merges it.
- The agent records the merge commit as the candidate and waits for the required CI on that exact commit. If the release branch advances, the candidate is invalidated.
- A pre-release qualification runs all applicable builds and tests against the exact candidate, and publication remains blocked until they pass.
- Once the version, branch, candidate, checks, and release inputs agree, the issue shows Ready to publish. The publication job shows the version, commit, qualification results, and expected outputs.
- The issue links to the publication job waiting at a new protected
releaseGitHub Environment. GitHub notifies the release-maintainers team, and one maintainer selects Approve and deploy. - Before publishing, the job repeats the safety checks and confirms that the tag is available. It creates an immutable GitHub release at the recorded commit and starts the existing release automation.
- The controller starts downstream work in dependency order and records every action in the issue. The agent observes workflows and public outputs, does not repeat active or completed work, and closes the issue only after the release-specific checklist passes.
Release Rules:
- Nothing is published until the release candidate passes validation and required checks. If a later step fails, the issue identifies what is incomplete, alerts the release owner, and tracks recovery through verification.
- RC starts at
M.m.0-rc1and then increments the highest RC. GA usesM.m.0and requires a prior RC. Patch increments the highest stable patch on the selected release branch. - The highest stable version becomes GitHub’s latest release. RCs and lower-version patches do not.
- The agent may open a repair pull request, but existing review, CI, and merge protections still apply.
POC Implementation:
Release Issue Generated with POC:
Example: 9.1.5: https://github.com/sarthakaggarwal97/valkey/issues/381
Source: valkey-io/valkey