fixup! Redesign release process and update instructions

CONTRIBUTING.md

@@ -532,7 +532,8 @@ git push upstream-push
 git fetch upstreams
 git checkout -B release-next upstream/release-next
 ```
-2. Create a Pull Request with **`develop`** as the base branch.
+2. Create a Pull Request for `release-next` with **`develop`** as
+   the base branch.
    1. Use the title "[TRIVIAL] Set version to X.X.X-bX".
    2. Instead of the default description template, use the following:
 ```
@@ -559,8 +560,9 @@ git push upstream-push release-next:develop
 5. Once this is done, forward progress on `develop` can continue
    (other PRs may be merged). *Note that during a formal code
    freeze, such as in the lead up to a release, only PRs related to
-   the release may be merged to `develop`.**
-6. Now create a Pull Request with **`release`** as the base branch.
+   the release may be merged to `develop`.*
+6. Now create a Pull Request for `release-next` with **`release`**
+   as the base branch.
    Instead of the default template, reuse and update the message from
    the previous release. Include the following verbiage somewhere in
    the description:
@@ -595,7 +597,7 @@ git push upstream-push release-next:release
 git fetch upstreams
 git log -1 --oneline
 # The output should look like:
-# 0123456789 (HEAD -> upstream/release-next, upstream/master, upstream/release, upstream/develop) Set version to 2.4.0-b1
+# 0123456789 (HEAD -> upstream/release-next, upstream/release, upstream/develop) Set version to 2.4.0-b1
 # Note that all of the upstream/develop, upstream/release
 # (and maybe upstream/master) are on this commit.
 # Other branches, including upstream-push, may
@@ -605,7 +607,8 @@ git log -1 --oneline
 git tag <version number>
 git push upstream-push <version number>
 ```
-9. Finally
+9. Delete the `release-next` branch.
+10. Finally
 [create a new release on Github](https://github.com/XRPLF/rippled/releases).
 
 ##### Final releases
@@ -616,7 +619,7 @@ The statement above:
      abandon one.
 
 **does not apply to final releases**. (A final release is any
-release that is not a beta or RC, such as 2.2.3.)
+release that is not a beta or RC, such as 2.2.0.)
 
 Only code that has already been tested and vetted across all three
 platforms should be included in a final release. Most of the time,
@@ -636,7 +639,7 @@ had a final release. Most of the time, development will have started
 on the next version, and will usually have changes in `develop`
 and often in `release`.
 
-Because git history is kept as linear as possible, the any fix and new
+Because git history is kept as linear as possible, any fix and new
 version will need to be applied against `master`.
 
 The spirit of most of the instructions above still apply, except that
@@ -658,7 +661,7 @@ git checkout -B master-next upstream/master-next
    so they can be merged directly in to it. Unlike `develop`, though,
    `master-next` can be thrown away and recreated if necessary.
 3. Some, but not all hotfixes will have RC versions commits. Betas are
-   usually not necesasry or appropriate. RCs are **NEVER** merged
+   usually not necessary or appropriate. RCs are **NEVER** merged
    into `master`.
 4. Steps 2-5 [above](#making-a-new-release) are skipped.
 5. The process picks up with step 6, but using **`master`** as the
@@ -702,7 +705,7 @@ This PR must be merged manually using a --ff-only merge. Do not use the Github U
 git rebase --rebase-merges upstream/develop
 # OR
 git reset --hard upstream/develop
-git git merge upstream/master
+git merge upstream/master
 ```
 7. When the PR is ready, ff-only merge it to `develop`.
 ```