Releasing a new Valkey version

Procedure for new releases

Start by coping this checklist into a new issue with the title of the release you are performing. Before you begin, validate that you have proper permissions to create a new branch and tag.

Checklist

• 1. Make sure all pull requests from the corresponding project are merged.
  1. Example 9.0. Use the filters to determine if everything is merged for the versions and release stage. For example, if you're launching rc1 then you'll need to confirm that there are no remaining Todo or In Progress statues remaining on the board with the "Need by" set to rc1. Using the filter text would look like: status:"In Progress",Todo need-by:rc1
• 2. First release candidate of a version Create a new release branch. We create branches for each major/minor, for example 7.2.0-rc1 will the branch create the branch name 7.2, but 7.2.4 will use 7.2
• 3. Submit a new PR to the correct release branch that updates the version.h file along with updating the release notes.
  1. For generating release notes, one way to get all of the commits is to use the release tool (see the next step). You can specify two separate tags, and it will automatically print the name of the commits for each of the PRs that had a "release-notes" tag.
  2. Tag all TSC members for review.
• 4. Cut a release here: https://github.com/valkey-io/valkey/releases/new. It should be based off of the target branch, e.g. "7.2", and the tag "7.2.5". When cutting the release, a new tag will automatically be created. Ensure that the release is named after the version, not the pull request.
• 5. Once the new version is released, this should trigger the automation workflow on the valkey-release-automation repository. The automation workflow will update the valkey-hashes with the new release. It will also open the PRs for the valkey-container repository and also on valkey-io.github.io
• 6. Review and merge the PR created by the automation on valkey-container to update with the new version docker images.
• 7. Review and merge the PR created by the automation on valkey-io.github.io to update website with the new version downloads page.
• 8. The valkey-doc repository:
  • If the version we're releasing is the latest version (i.e. not a patch release of an older version nor a release candidate), update the version info in the top of the Makefile. Example:

    # Version info
    VERSION ?= 8.0.2
    DATE ?= 2025-01-08
    

    This version info is used in the headers and footers of man pages by default, but can be overridden. Make the change as a PR to the doc repo and merge it.
  • Tag the version on the main branch. Example:

    git tag -m "Documentation for Valkey 8.0.2" 8.0.2
    git push --tags
    

  • Note: Our docs are not versioned, but we tag it anyway whenever we release a new version to get reproducible builds. This was requested by the Fedora packagers.

9. Major/Minor Only Additional doc repo updates:
   1. Run the ruby script to extract module API docs (extracted from comments in src/module.c)

   ./utils/generate-module-api-doc.rb > $DOC_REPO/topics/modules-api-ref.md
   

   2. Update the List of supported versions in the doc repo on topics/releases.md
10. Patch only Move the released PRs from To be backported to Done in the project board.
11. RC2 only Adjust project board workflow. If there is a rule to automatically move merged PRs to Done, change it so a merged PR is moved to To be backported instead. Create the To be backported column if needed.

(This checklist was sourced from the Valkey Wiki: https://github.com/valkey-io/valkey/wiki/Releasing-a-new-Valkey-version)