24

Release Process

Amphitryon0 edited this page 2025-08-06 17:58:41 -05:00

Table of Contents

• Introduction
• Details

Introduction

Creating a Dolphin Release does require some steps, but if you know what to do it's fairly straightforward.

Releases are versioned as follows: YYMM, where YY is the current year, and MM is the current month. Hotfix releases are versioned as follows: YYMMp, where p is the hotfix letter. For example, 2407 would be a release made in July 2024, and 2407a would be the first hotfix for that release.

Releases can only be created by core developers.

Details

1. Perform a translation sync with Transifex if creating a major release.
2. Create a new branch: git checkout -b <branch name> <base commit or tag>
   • If creating a major release, name the branch release-prep-YYMM and base it on the master branch.
   • If creating a hotfix release, name the branch release-prep-YYMMp and base it on the tag of the last release.
3. Add any necessary commits.
   • If creating a major release and the previous release was a hotfix, merge the hotfix branch into the new release branch. The tree should generally be the same here as before the merge with the exception of CMake/ScmRevGen.cmake.
   • If creating a hotfix release, cherry-pick the changes from master.
4. Update the version constants in CMake/ScmRevGen.cmake, and commit the result.
   • Set DOLPHIN_VERSION_MAJOR to YYMM.
   • Set DOLPHIN_VERSION_MINOR to the patch number. If creating a hotfix release, use the number corresponding to the patch letter (for example, a is 1, b is 2, etc). Otherwise, set to 0.
     • This field must be set to a number as CPack does not support non-numerical values in the minor or patch version fields.
   • The version constants commit should be the last one in the branch.
5. Push the branch to GitHub: git push -u origin <branch name>.
6. Smoke test the produced builds.
   • The builds can be downloaded at https://dolphin-emu.org/download/list/release-prep-YYMM/1/.
   • Now is the time to fix any last-minute issues. Additional builds can be created by pushing new commits to GitHub (using --force-with-lease). Remember that the version constants commit should be the last one in the branch, so the branch should be rebased or abandoned in favor of a fresh one.
7. Create an annotated tag: git tag -a <version> -m "Release for some date"
8. Push the tag to GitHub: git push origin <version>.
9. The release builds will automatically show up on the normal download page.
10. Publish the corresponding Progress Report, if any.
    • After publishing, post the link to the Progress Report onto Twitter, Mastodon, Bluesky, etc.
11. Push the new release to the beta update track through the Update Tracks interface on the dolphin-emu.org admin panel.
12. If this is a regular release, merge the release branch back into master: git checkout master, git merge --no-ff <branch name>.
    • --no-ff is important, as we require a merge commit.

Dolphin GitHub Wiki

• Building

  • Linux
  • Windows
  • macOS
  • OpenBSD

• Feature explanations

  • FIFO Player Overview
  • Running Unit Tests
  • IOS Overview
  • Post Processing Shaders
  • Sys and User Folders

• Dolphin Infrastructure

  • About Dolphin's CI Bot
  • Buildbot Overview
  • Release Process
  • Auto Update Internals
  • Who Can Access What?

• Reference

  • Zelda Microcode
  • GameCube Action Replay Code Types
  • GameCube Action Replay Code Types (Simple Version)

Homepage | Project Site | Forums | Wiki | Issue Tracker | Coding Style | Transifex Page