diff --git a/docs/Release-Process.md b/docs/Release-Process.md
index e311e7c0b8..a0d08e58b8 100644
--- a/docs/Release-Process.md
+++ b/docs/Release-Process.md
@@ -6,7 +6,7 @@
 - [gh](https://cli.github.com)
   * Install and configure the GitHub CLI (gh) as detailed at https://docs.github.com/en/github-cli/github-cli/quickstart#prerequisites .
 
-- GitHub permissions to push tags and create releases in Kata repositories.
+- GitHub permissions to push tags and create releases in the Kata repository.
 
 - GPG configured to sign git tags. https://docs.github.com/en/authentication/managing-commit-signature-verification/generating-a-new-gpg-key
 
@@ -16,9 +16,9 @@
 ## Release Process
 
 
-### Bump all Kata repositories
+### Bump the Kata repository
 
-  Bump the repositories using a script in the Kata packaging repo, where:
+  Bump the repository using the `./update-repository-version.sh` script in the Kata [release](../tools/packaging/release) directory, where:
   - `BRANCH=<the-branch-you-want-to-bump>`
   - `NEW_VERSION=<the-new-kata-version>`
   ```
@@ -28,16 +28,16 @@
   $ ./update-repository-version.sh -p "$NEW_VERSION" "$BRANCH"
   ```
 
-### Merge all bump version Pull requests
+### Merge the bump version Pull request
 
-  - The above step will create a GitHub pull request in the Kata projects. Trigger the CI using `/test` command on each bump Pull request.
+  - The above step will create a GitHub pull request in the Kata repository. Trigger the CI using `/test` command on the bump Pull request.
   - Check any failures and fix if needed.
-  - Work with the Kata approvers to verify that the CI works and the pull requests are merged.
+  - Work with the Kata approvers to verify that the CI works and the pull request is merged.
 
-### Tag all Kata repositories
+### Tag the Kata repository
 
-  Once all the pull requests to bump versions in all Kata repositories are merged,
-  tag all the repositories as shown below.
+  Once the pull request to bump version in the Kata repository is merged,
+  tag the repository as shown below.
   ```
   $ cd ${GOPATH}/src/github.com/kata-containers/kata-containers/tools/packaging/release
   $ git checkout  <kata-branch-to-release>
@@ -45,24 +45,6 @@
   $ ./tag_repos.sh -p -b "$BRANCH" tag
   ```
 
-### Point tests repository to stable branch
-
-  If your release changes a major or minor version number(not a patch release), then the above 
-  `./tag_repos.sh` script will create a new stable branch in all the repositories in addition to tagging them.
-  This happens when you are making the first `rc` release for a new major or minor version in Kata.
-  In this case, you should modify the `tests` repository to point to the newly created stable branch and not the `main` branch.
-  The objective is that changes in the CI on the main branch will not impact the stable branch.
-
-  In the test directory, change references of the `main` branch to the new stable branch in:
-  * `README.md`
-  * `versions.yaml`
-  * `cmd/github-labels/labels.yaml.in`
-  * `cmd/pmemctl/pmemctl.sh`
-  * `.ci/lib.sh`
-  * `.ci/static-checks.sh`
-
-  See the commits in [the corresponding PR for stable-2.1](https://github.com/kata-containers/tests/pull/3504) for an example of the changes.
-
 ### Check Git-hub Actions
 
   We make use of [GitHub actions](https://github.com/features/actions) in this [file](../.github/workflows/release.yaml) in the `kata-containers/kata-containers` repository to build and upload release artifacts. This action is auto triggered with the above step when a new tag is pushed to the `kata-containers/kata-containers` repository.
@@ -71,7 +53,7 @@
 
 ### Create release notes
 
-  We have a script in place in the packaging repository to create release notes that include a short-log of the commits across Kata components.
+  We have the `./release-notes.sh` script in the [release](../tools/packaging/release) directory to create release notes that include a short-log of the commits.
 
   Run the script as shown below: