From 2c081ed39fa2c447e0ac798143573644850815fc Mon Sep 17 00:00:00 2001
From: Manan Gupta <manan@planetscale.com>
Date: Mon, 17 Jul 2023 15:27:21 +0530
Subject: [PATCH] feat: update the release process doc

Signed-off-by: Manan Gupta <manan@planetscale.com>
---
 docs/release-process.md | 38 +++++++++++++++++++++++++++++---------
 1 file changed, 29 insertions(+), 9 deletions(-)

diff --git a/docs/release-process.md b/docs/release-process.md
index 7e14a8205..c27bfab8d 100644
--- a/docs/release-process.md
+++ b/docs/release-process.md
@@ -2,6 +2,8 @@
 
 This doc describes the process to cut a new release of Vitess Operator.
 
+-------------------
+
 ## Prepare for Release
 
 For each major release of the Operator, there is a release branch, for instance: `release-2.7`.
@@ -19,6 +21,8 @@ build/Dockerfile.release
 go.mod
 ```
 
+-------------------
+
 ### Update Compatibility Table
 
 Add a new entry for the planned minor version to the [compatibility table](https://github.com/planetscale/vitess-operator/blob/main/README.md#compatibility)
@@ -38,9 +42,7 @@ time that we update to build against a newer Vitess release.
 The Kubernetes library version is determined by the version of [Operator SDK](https://github.com/operator-framework/operator-sdk)
 that's in use.
 
-### Update the test output
-
-The `upgrade.sh`, `backup_restore_test.sh` and `vtorc_vtadmin_test.sh` files must be updated with the proper release increment. Change the `verifyVtGateVersion` function calls to use the proper version (next version and new old version).
+-------------------
 
 ## Cut Release
 
@@ -95,7 +97,7 @@ OLD_VITESS_VERSION="13.0.0" NEW_VITESS_VERSION="14.0.3" NEW_OPERATOR_VERSION="2.
 Here we want to release the version `2.7.4`. It will be tested against Vitess `v14.0.3`. The upgrade downgrade tests will begin with Vitess `v13.0.0`.
 
 [Docker Hub](https://hub.docker.com/repository/docker/planetscale/vitess-operator)
-hould automatically detect the new tag and begin building a new image.
+should automatically detect the new tag and begin building a new image.
 
 Follow the instructions prompted by the `do_release.sh` script. You will need to push the tag and push the temporary branch to finally create a Pull Request. The Pull Request should be merged onto the release branch.
 
@@ -103,15 +105,33 @@ Follow the instructions prompted by the `do_release.sh` script. You will need to
 > Make sure to Normal Merge the pull request i.e. merge the pull request with merge commit and not a squash merge. This is required because we create the tag
 from the pull request, so in order to have the tag on the release branche's history, it has to be a normal merge.
 
-##### On `main`
+##### Update the test output
 
-Once you have done the release on the release branch, there are several steps to follow on `main`.
+The `upgrade_test.sh`, `backup_restore_test.sh` and `vtorc_vtadmin_test.sh` files must be updated with the proper release increment. Change the `verifyVtGateVersion` function calls to use the proper version (current version being released and latest previous version (only used in `upgrade_test.sh`)).
 
-- The `vitess/lite` image tag must be changed in [101_initial_cluster.yaml](..%2Ftest%2Fendtoend%2Foperator%2F101_initial_cluster.yaml). The latest Vitess release tag must be used.
-- We must copy the [operator-latest.yaml](..%2Ftest%2Fendtoend%2Foperator%2Foperator-latest.yaml) file we created during the release onto `main`'s [operator.yaml](..%2Ftest%2Fendtoend%2Foperator%2Foperator.yaml) file.
-- Bump the `planetscale/vitess-operator` image tag to the latest version we just released in [operator.yaml](..%2Ftest%2Fendtoend%2Foperator%2Foperator.yaml).
+##### CI Failures
+
+> **Note**
+> It is likely that the buildkite tests will fail on the release PR initially because of the unavailability of the latest vitess and vitess-operator docker images. This however doesn't block the release. The tests should be restarted after the said images are built and available.
+
+-------------------
 
 ### UI Release
 
 Create a [new release](https://github.com/planetscale/vitess-operator/releases/new)
 in GitHub UI and make sure to add the release-notes from the docs (if any).
+
+-------------------
+
+### On `main`
+
+> **Note**
+> This step is only required for the latest major release and patch releases of the latest major release.
+
+Once you have done the release on the release branch, there are several steps to follow on `main`.
+
+- The `vitess/lite` image tag must be changed in [101_initial_cluster.yaml](..%2Ftest%2Fendtoend%2Foperator%2F101_initial_cluster.yaml). The latest Vitess release tag must be used.
+- We must copy the [operator-latest.yaml](..%2Ftest%2Fendtoend%2Foperator%2Foperator-latest.yaml) file we created during the release onto `main`'s [operator.yaml](..%2Ftest%2Fendtoend%2Foperator%2Foperator.yaml) file. Once copied, remove the change that adds `imagePullPolicy: Never` and update the `image: vitess-operator-pr:latest` to use the docker image of latest vitess-operator patch like `image: planetscale/vitess-operator:v2.10.0`.
+- The `upgrade_test.sh`, `backup_restore_test.sh` and `vtorc_vtadmin_test.sh` files must be updated with the proper release increment. Change the `verifyVtGateVersion` function calls to use the proper version (new snapshot Vitess version and current version being released (only used in `upgrade_test.sh`)).
+
+