Create a stable branch for every major or minor release

1 files changed, 29 insertions, 28 deletions

diff --git a/PROCESS.md b/PROCESS.md
index 9b15ac3e..849d4bf8 100644
--- a/PROCESS.md
+++ b/PROCESS.md
@@ -23,26 +23,41 @@ Pages is tightly coupled to GitLab itself. To align with GitLab's
 new versions of GitLab Pages are released before the 7th of each month (assuming
 any changes have been made). To do so:
 
+* For major and minor releases, create a stable branch if it doesn't already exist:
+
+    ```shell
+    git checkout -b X-Y-stable master # MAJOR.MINOR
+    git push X-Y-stable https://gitlab.com/gitlab-org/gitlab-pages.git
+    git push X-Y-stable https://dev.gitlab.org/gitlab/gitlab-pages.git
+    ```
+
 * Review the list of changes since the last release and create a changelog
 * Decide on the version number by reference to the [Versioning](#versioning) section
 * [Create a new issue](https://gitlab.com/gitlab-org/gitlab-pages/issues/new)
   containing the changelog
-* Create a new MR, modifying the `CHANGELOG` and `VERSION` files
-* Once the MR is merged, create a signed+annotated tag pointing to the **merge commit** on **master**, e.g.:
+* Create a new merge request, modifying the `CHANGELOG` and `VERSION` files, targeting the correct stable branch
+* Once it's merged, create a signed+annotated tag pointing to the **merge commit** on the **stable branch**, e.g.:
 
     ```shell
-    git tag -a -s -m "Release v1.0.0" v1.0.0
+    git fetch origin 1-0-stable
+    git tag -a -s -m "Release v1.0.0" v1.0.0 origin/1-0-stable
     git push v1.0.0 https://gitlab.com/gitlab-org/gitlab-pages.git
     git push v1.0.0 https://dev.gitlab.org/gitlab/gitlab-pages.git
     ```
 
 * Create a merge request against [GitLab](https://gitlab.com/gitlab-org/gitlab-ce) to update `GITLAB_PAGES_VERSION`
 
+As each release is made, the `CHANGELOG` for the stable branch will be updated
+to contain content not in the **master** branch. To resolve this, the stable
+branches may be merged to **master**. For more complicated merges, it may be
+easier to pick just the updates to `CHANGELOG`.
+
 ## Stable releases
 
 Typically, release tags point to a specific commit on the **master** branch. As
 the Pages repository experiences a low rate of change, this allows most releases
-to happen in conformance with semver, without the overhead of multiple [stable branches](https://docs.gitlab.com/ee/workflow/gitlab_flow.html).
+to happen in conformance with semver, without the overhead of multiple
+[stable branches](https://docs.gitlab.com/ee/workflow/gitlab_flow.html).
 
 A bug fix may required in a particular version after the **master** branch has
 moved on. This may happen between the 7th and 22nd of a release month, relating
@@ -54,27 +69,13 @@ versions to release.
 
 In either case, the fix should first be developed against the master branch,
 taking account of the [security release workflow](https://about.gitlab.com/handbook/engineering/workflow/#security-issues)
-if necessary. Once ready, the fix should be merged to master.
-
-To create the stable releases, create a stable branch if it doesn't already
-exist:
-
-```
-git checkout -b X-Y-stable vX.Y.Z # MAJOR.MINOR.PATCH
-git push X-Y-stable https://gitlab.com/gitlab-org/gitlab-pages.git
-git push X-Y-stable https://dev.gitlab.org/gitlab/gitlab-pages.git
-```
-
-Now that the branch exists, the fix may be cherry-picked into it, and a new
-release made in the same way as defined above. In these cases, the tag is
-created to point at the **merge commit** of the **X-Y-stable** branch, rather
-than pointing at master.
-
-As each release is made, the `CHANGELOG` will be updated to contain content not
-in the **master** branch. To resolve this, the stable branches may be merged to
-**master**. For more complicated merges, it may be easier to pick just the
-updates to `CHANGELOG`.
-
-The `X-Y-stable` branch in [GitLab](https://gitlab.com/gitlab-org/gitlab-ce)
-should be updated to refer to the correct stable release of GitLab Pages. In
-general, these branches should only ever have their patch versions incremented.
+if necessary. Once ready, the fix should be merged to master, where it will be
+included in the next major or minor release as usual.
+
+The fix may be cherry-picked into each relevant stable branch, and a new patch
+release made in the same way as defined above.
+
+When updating `GITLAB_PAGES_VERSION` in the [GitLab](https://gitlab.com/gitlab-org/gitlab-ce)
+repository, you should target the relevant `X-Y-stable` branches there. In
+general, these branches should only ever have the patch version of GitLab pages
+incremented.