Merge branch 'sabrams-master-patch-94154' into 'master'

Revise the release process for managed versioning

See merge request https://gitlab.com/gitlab-org/gitlab-pages/-/merge_requests/842

Merged-by: Alessio Caiazza <acaiazza@gitlab.com>
Approved-by: Alessio Caiazza <acaiazza@gitlab.com>
Reviewed-by: Alessio Caiazza <acaiazza@gitlab.com>
Reviewed-by: Steve Abrams <sabrams@gitlab.com>
Co-authored-by: Steve Abrams <sabrams@gitlab.com>

3 files changed, 30 insertions, 75 deletions

diff --git a/.gitlab/issue_templates/release.md b/.gitlab/issue_templates/release.md
deleted file mode 100644
index 7b985184..00000000
--- a/.gitlab/issue_templates/release.md
+++ /dev/null
@@ -1,45 +0,0 @@
-- [ ] Set the milestone on this issue
-- Decide on the version number by reference to
-    the [Versioning](https://gitlab.com/gitlab-org/gitlab-pages/blob/master/PROCESS.md#versioning)
-    * Typically if you want to release code from current `master` branch you will update `MINOR` version, e.g. `1.12.0` -> `1.13.0`. In that case you **don't** need to create stable branch
-    * If you want to backport some bug fix or security fix you will need to create a stable branch `X-Y-stable` on the [security project](https://gitlab.com/gitlab-org/security/gitlab-pages). You will need maintainer access to create the stable branch.
-- [ ] Create an MR for [gitlab-pages project](https://gitlab.com/gitlab-org/gitlab-pages).
-    You can use [this MR](https://gitlab.com/gitlab-org/gitlab-pages/-/merge_requests/711) as an example.
-    - [ ] Update `VERSION`, and push your branch
-    - [ ] Update `CHANGELOG` by running `GITLAB_PRIVATE_TOKEN= make changelog`, note that you need to create a personal access token
-    - [ ] Assign to reviewer
-- [ ] Once `gitlab-pages` is merged create a signed+annotated tag pointing to the **merge commit** on the **stable branch**
-    In case of `master` branch:
-    ```shell
-    git fetch origin master
-    git fetch dev master
-    git tag -a -s -m "Release v1.0.0" v1.0.0 origin/master
-    ```
-    In case of `stable` branch:
-    ```shell
-    git fetch origin 1-0-stable
-    git fetch dev 1-0-stable
-    git tag -a -s -m "Release v1.0.0" v1.0.0 origin/1-0-stable
-    ```
-- [ ] Verify that you created tag properly:
-    ```shell
-    git show v1.0.0
-    ```
-    it should include something like:
-    * ```(tag: v1.0.0, origin/master, dev/master, master)``` for `master`
-    * ```(tag: v1.0.1, origin/1-0-stable, dev/1-0-stable, 1-0-stable)``` for `stable` branch
-- [ ] Push this tag to origin(**Skip this for security release!**)
-    ```shell
-    git push origin v1.0.0
-    ```
-- [ ] Wait for tag to be mirrored to `dev` or push it:
-    ```shell
-    git push dev v1.0.0
-    ```
-- [ ] Create an MR for [gitlab project](https://gitlab.com/gitlab-org/gitlab).
-    You can use [this MR](https://gitlab.com/gitlab-org/gitlab/-/merge_requests/82901) as an example.
-    - [ ] Update `GITLAB_PAGES_VERSION`
-    - [ ] Added `Changelog: added` footer to your commit
-    - [ ] Assign to a reviewer
-
-/label ~backend ~"Category:Pages" ~"section::dev" ~"devops::create" ~"group::editor" ~"type::maintenance"
diff --git a/.gitlab/merge_request_templates/Security Release.md b/.gitlab/merge_request_templates/Security Release.md
index 2f7b41d7..7f115f16 100644
--- a/.gitlab/merge_request_templates/Security Release.md
+++ b/.gitlab/merge_request_templates/Security Release.md
@@ -26,9 +26,8 @@ When submitting a merge request for gitlab-pages, CE and EE merge requests for u
 
 ## Reviewer checklist
 
-- [ ] Correct milestone is applied and the title is matching across all backports
-- [ ] Merge this merge request
-- [ ] Create corresponding tag and push it to https://gitlab.com/gitlab-org/security/gitlab-pages
+- [ ] Correct milestone is applied and the title is matching across all backports.
+- [ ] Approve the MR. Do not merge it, release managers will assist with merging at the time of release.
 
 [CHANGELOG entry]: https://docs.gitlab.com/ee/development/changelog.html#overview
 
diff --git a/PROCESS.md b/PROCESS.md
index 37708dd8..f32731c6 100644
--- a/PROCESS.md
+++ b/PROCESS.md
@@ -16,41 +16,42 @@ rewritten. Tags should never be deleted.
 
 ## Releasing
 
-Pages is tightly coupled to GitLab itself. To align with GitLab's
-[development month](https://gitlab.com/gitlab-org/gitlab-ce/blob/master/PROCESS.md),
-new versions of GitLab Pages are released before the 7th of each month (assuming
-any changes have been made).
-To do so create [release issue](https://gitlab.com/gitlab-org/gitlab-pages/issues/new?issuable_template=release) and follow the instructions.
+[GitLab Pages] releases are tagged automatically by [Release Tools] when a Release Manager 
+tags a GitLab version.
+
+The version of GitLab Pages used will depend on the `GITLAB_PAGES_VERSION` file in 
+the [`gitlab-org/gitlab`](https://gitlab.com/gitlab-org/gitlab) repository. This file
+is managed manually, so when changes to GitLab Pages are ready to be released with GitLab, the
+target commit SHA from the GitLab Pages default branch should be committed to the
+`GITLAB_PAGES_VERSION` file on the `gitlab-org/gitlab` default branch. When GitLab.com
+is deployed, the new version of GitLab Pages will be used. When GitLab is tagged for a monthly release,
+the version of GitLab Pages from the selected deployment of GitLab will be used for tagging
+GitLab Pages.
 
 ## 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).
+Each month, when GitLab is released, a new stable branch will be created in alignment
+with the version of GitLab being released. For example, release of version 15.2.0 
+will result in a branch named `15-2-stable` being created on [GitLab Pages].
 
-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
-to the **previous** release, or at any time for a security fix.
+To backport a change: 
 
-GitLab may backport security fixes for up to three releases, which may
-correspond to three separate minor versions of GitLab Pages - and so three new
-versions to release. See [Security releases](#Security releases) for the details.
-
-In either case, the fix should first be developed against the master branch.
-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)
-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.
+1. Develop an MR to fix the bug against the master branch.
+1. Once ready, the MR should be merged to master, where it will be included in the next major or minor release as usual.
+1. Create a merge request for `gitlab-org/gitlab` that updates `GITLAB_PAGES_VERSION` with the
+merge commit SHA from the GitLab Pages default branch to deploy the changes.
+1. To create a backport MR for a given stable version:
+   1. Create a new branch off of the stable branch for the targeted version.
+   1. Cherry-pick the commit onto the new branch.
+   1. Open an MR targeting the relevant stable branch.
+   1. Have the MR reviewed and merged. Note: security backports should not be merged, see [security releases](#Security releases) for more details.
+1. When release managers tag a patch or security release, the stable branch will be tagged automatically.
 
 ## Security releases
 
+This process is currently [under discussion](https://gitlab.com/gitlab-com/gl-infra/delivery/-/issues/2746). Please consult with release managers
+about any process changes in the interim. 
+
 Pages security releases are built on top of the [GitLab Security Release process]. Engineers follow
 the same steps stated on the [Security Developer] guidelines with some adjustments: