Document the new release process.

README_releasing.txt

@@ -4,61 +4,58 @@ How to Make a Release
 This guide explains how to make an Allegro release. This all assumes that we're
 on Linux.
 
-1.  Write a changelog file. This is located in docs/src/changes-5.x.txt.
+1.  Starting with the 5.1 branch, pick a commit which you want to be the base of
+    the release branch. Typically this will be HEAD, but if there are some
+    unbaked commits there, you may want to use an earlier commit. Call this
+    branch with the new release name (e.g. 5.1.12 in this case):
+
+        git branch 5.1.12 5.1
+
+    From now on, aside from changing the version numbers, all commits on this
+    release branch should be cherry-picked from the 5.1 branch. For all
+    cherry-picks, prefer using the -x switch, like so:
+
+        git cherry-pick -x badf00d
+
+2.  On the 5.1 branch, bump the version to the next release and update the
+    dates. This is done in `include/allegro5/base.h`. Also, change
+    ALLEGRO_VERSION in `CMakeLists.txt`. Commit this change.
+
+3.  Write a changelog file. This is located in docs/src/changes-5.x.txt.
 
     Typically you will want to look through the commits made since the last
-    release, e.g. using `git log <last_release_tag>..HEAD` (e.g.
-    `git log 5.1.8..HEAD`). Follow the format of the previous changelogs. It's
-    up to you how to determine who are the 'main developers'. For the 5.1.9
-    release, I've abitrarily determined it to be developers who've committed 95%
-    of the lines of code (this isn't very important). You probably will want to
-    have other developers check it over in case something is wrong/missing.
+    release, e.g. using `git log <last_release>..<this_release>` (e.g. `git log
+    5.1.11..5.1.12`). Follow the format of the previous changelogs. It's up to
+    you how to determine who are the 'main developers'. For the 5.1.9+ release,
+    I've abitrarily determined it to be developers who've committed 95% of the
+    lines of code (this isn't very important). You probably will want to have
+    other developers check it over in case something is wrong/missing. Commit
+    this change.
 
-2.  Commit the changelog changes.
+4.  We are now done with the 5.1 branch. You can push these changes to github.
+    Check out the release branch now.
 
-3.  Bump the version from "GIT" to "WIP" if it's unstable, or remove "GIT" if
+5.  Cherry-pick the commit with the changelog onto this branch.
+
+6.  Bump the version from "GIT" to "WIP" if it's unstable, or remove "GIT" if
     it's stable, while preserving the major, minor and patch numbers, but
-    increasing the release number to 1. Also, update the dates at this time.
+    increasing the release number by 1. Also, update the dates at this time.
     This is all done in `include/allegro5/base.h`. Commit this change.
 
-4.  Tag the previous commit with the same version number (e.g. "5.1.9" if you're
-    releasing 5.1.9. An example command would be:
+7.  Tag the previous commit with the same version number and the release number
+    (e.g. "5.1.12.0" if you're releasing 5.1.12. An example command would be:
 
-        git tag -a -m "Tag 5.1.9 (WIP)" 5.1.9
+        git tag -a -m "Tag 5.1.12.0 (WIP)" 5.1.12.0
 
-5.  Create the source archives by running `misc/create_release_archives.sh` and
+8.  Create the source archives by running `misc/create_release_archives.sh` and
     passing in the release version. This will create 3 source archives (.tar.gz,
     .7z and .zip) in the current directory. And example invocation would be:
 
-        ./misc/create_release_archives.sh 5.1.9
-
-6.  Upload these archives to Sourceforge. Make a directory with the release
-    number at https://sourceforge.net/projects/alleg/files/allegro (or
-    allegro-unstable) and upload the 3 archives there.
-
-7.  If this is a stable release, you also need to generate new documentation.
-    Just run the build with documentation enabled, and then create a new
-    directory in /home/project-web/alleg/htdocs_parts/staticweb/a5docs (this is
-    Sourceforge FTP, at web.sourceforge.net:22). You also need to create a
-    symlink to this new directory in /home/project-web/alleg/htdocs/a5docs (I
-    believe logging into the shell is the best way to do this).
-
-    The unstable documentation is currently automatically generated (courtesy of
-    a cron script maintained by Elias), so if this is an unstable release,
-    nothing needs to be done.
-
-8.  Bump the version to the next release. E.g. "5.1.9 (WIP)" becomes
-    "5.1.10 (GIT)". Make sure to also decrease the release number back to 0.
-    This is all done in `include/allegro5/base.h`. Also, change ALLEGRO_VERSION
-    in `CMakeLists.txt`. Commit this change. At this point you can push to
-    sourceforge. Don't forget to push with `git push --tags`!
-
-9.  Update website. For release announcement, add a new file to the en/news
-    directory (in the allegrowww2 repository). Change the files in the changes
-    or changes-unstable directory (as appropriate). Change the download links
-    in en/downloads. Run the makefile and then upload the files in the OUT
-    directory to /home/project-web/alleg/htdocs_parts/generatedweb (again,
-    Sourceforge FTP). Commit after running the makefile (as it updates some
-    files).
-
-10. Make an announcement on allegro.cc. You're done!
+        ./misc/create_release_archives.sh 5.1.12.0
+
+    Typically for the first release we drop the release number, so rename the
+    archives accordingly.
+
+9.  Upload the source archives to gna.org. The command to use would be something like this:
+
+        rsync -avr --rsh="ssh" allegro-5.1.12.* <user>@download.gna.org:/upload/allegro/allegro-unstable/5.1.12