ShuriZma
/
dolphin
mirror of https://github.com/dolphin-emu/dolphin.git
1
0
Fork 0
Code Issues Packages Projects Releases Wiki Activity

clarify how hotfix releases are versioned

OatmealDome 2024-07-11 14:34:28 -04:00
parent 50754e205f
commit 23a7b4e5ce
1 changed files with 6 additions and 6 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

12
Release-Process.md

@ -2,14 +2,14 @@
Creating a Dolphin Release does require some steps, but if you know what to do it's fairly straightforward. 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. If creating a hotfix release, a letter is appended to the end of the version number. For example, `2407a` would be the first hotfix for a release made in July 2024. 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](https://github.com/orgs/dolphin-emu/teams/core-developers). Releases can only be created by [core developers](https://github.com/orgs/dolphin-emu/teams/core-developers).
## Details ## Details
1. Perform a translation sync with Transifex if creating a major release. 1. Perform a translation sync with Transifex if creating a major release.
2. Create a new branch named `release-prep-YYMM`: `git checkout -b release-prep-YYMM <commit or tag>` 2. Create a new branch named `release-prep-YYMMp`: `git checkout -b release-prep-YYMMp <commit or tag>`
* If creating a major release, use the commit that the release should be based on. * If creating a major release, use the commit that the release should be based on.
* If creating a hotfix release, use the tag of the last release. * If creating a hotfix release, use the tag of the last release.
3. Cherry pick any necessary commits. 3. Cherry pick any necessary commits.
@ -17,13 +17,13 @@ Releases can only be created by [core developers](https://github.com/orgs/dolphi
* Set `DOLPHIN_VERSION_MAJOR` to `YYMM`. * 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`. * 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](https://gitlab.kitware.com/cmake/cmake/-/issues/19310). * This field must be set to a number [as CPack does not support non-numerical values in the minor or patch version fields](https://gitlab.kitware.com/cmake/cmake/-/issues/19310).
5. Push the branch to GitHub: `git push -u origin release-prep-YYMM`. 5. Push the branch to GitHub: `git push -u origin release-prep-YYMMp`.
6. Smoke test the produced builds. 6. Smoke test the produced builds.
* The builds can be downloaded at `https://dolphin-emu.org/download/list/release-prep-YYMM/1/`. * 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. * Now is the time to fix any last-minute issues. Additional builds can be created by pushing new commits to GitHub.
7. Create an **annotated** tag: `git tag -a YYMM -m "Release for some date"` 7. Create an **annotated** tag: `git tag -a YYMMp -m "Release for some date"`
8. Push the tag to GitHub: `git push origin YYMM`. 8. Push the tag to GitHub: `git push origin YYMMp`.
9. The release builds will automatically show up on the normal download page. 9. The release builds will automatically show up on the normal download page.
10. Publish the corresponding Progress Report, if any. 10. Publish the corresponding Progress Report, if any.
* After publishing, post the link to the Progress Report onto Twitter, Mastodon, Bluesky, etc. * After publishing, post the link to the Progress Report onto Twitter, Mastodon, Bluesky, etc.
11. Merge the release branch back into master: `git checkout master`, `git merge --no-ff release-prep-YYMM`. 11. Merge the release branch back into master: `git checkout master`, `git merge --no-ff release-prep-YYMMp`.