#4494·valkey

[NEW] Low-Touch Releases for Valkey OSS

Author: sarthakaggarwal97Created Aug 20, 2026Updated Sep 17, 2026
Labelsenhancement

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.

Image

For a 9.2.0 GA release:

  • An authorized release owner runs Start release with branch 9.2, intent GA, 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.0 and opens Release 9.2.0 in Valkey. A second 9.2 request 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 release GitHub 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-rc1 and then increments the highest RC. GA uses M.m.0 and 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