SDL: Updated the release checklist

From 27f69c772c4850e37be0da192a7c71f9542b7407 Mon Sep 17 00:00:00 2001
From: Sam Lantinga <[EMAIL REDACTED]>
Date: Fri, 1 Nov 2024 19:40:47 -0700
Subject: [PATCH] Updated the release checklist

This will help me remember to create the archives _after_ tagging the release.
---
 docs/release_checklist.md | 35 ++++++++++++++---------------------
 1 file changed, 14 insertions(+), 21 deletions(-)

diff --git a/docs/release_checklist.md b/docs/release_checklist.md
index 7f7629447848d..afa3de058f4a8 100644
--- a/docs/release_checklist.md
+++ b/docs/release_checklist.md
@@ -1,16 +1,15 @@
 # Release checklist
 
-* Run `build-scripts/create-release.py -R libsdl-org/SDL --ref <git-ref>` to command
-  GitHub Actions to start creating release assets.
-  It's advisable to run this script regularly, and also prior to any release step.
-  When creating the release assets, `<git-ref>` must be the release tag
-  This makes sure the revision string baked into the archives is correct.
+* Run `build-scripts/create-release.py -R libsdl-org/SDL --ref <branch>` to do
+  a dry run creating the release assets. Verify that the archives are correct.
 
-* When changing the version, run `build-scripts/update-version.sh X Y Z`,
-  where `X Y Z` are the major version, minor version, and patch level. So
-  `3 8 1` means "change the version to 3.8.1". This script does much of the
-  mechanical work.
+* Tag the release, e.g. `git tag release-3.8.0; git push --tags`
 
+* Run `build-scripts/create-release.py -R libsdl-org/SDL --ref <release-tag>`
+  to have GitHub Actions create release assets. This makes sure the revision
+  string baked into the archives is correct.
+
+* Create a GitHub release and attach the archives you just generated.
 
 ## New feature release
 
@@ -22,13 +21,15 @@
 
 * Do the release
 
-* Update the website file include/header.inc.php to reflect the new version
+* Immediately create a branch for patch releases, e.g. `git branch release-3.EVEN.x`
 
-## New bugfix release
+* Bump version number from 3.EVEN.0 to 3.(EVEN+1).0
 
-* Check that no new API/ABI was added
+    * `./build-scripts/update-version.sh 3 EVEN+1 0`
+
+* Update the website file include/header.inc.php to reflect the new version
 
-    * If it was, do a new feature release (see above) instead
+## New bugfix release
 
 * Bump version number from 3.Y.Z to 3.Y.(Z+1) (Y is even)
 
@@ -38,14 +39,6 @@
 
 * Update the website file include/header.inc.php to reflect the new version
 
-## After a feature release
-
-* Create a branch like `release-3.4.x`
-
-* Bump version number to 3.ODD.0 for next development branch
-
-    * `./build-scripts/update-version.sh 3 ODD 0`
-
 ## New development prerelease
 
 * Bump version number from 3.Y.Z to 3.Y.(Z+1) (Y is odd)