Update RELEASING.md (#3001)

Author: lzchen

RELEASING.md

@@ -9,8 +9,9 @@
       (otherwise the workflow will pick up the version from `main` and just remove the `.dev` suffix).
   * Review the two pull requests that it creates.
     (one is targeted to the release branch and one is targeted to `main`).
-    * Merge the one targeted towards the release branch.
-    * The builds will fail for the `main` pr because of validation rules. Follow the [release workflow](https://github.com/open-telemetry/opentelemetry-python/blob/main/RELEASING.md) for the core repo up until this same point. Change the SHAs of each PR to point at each other to get the `main` builds to pass.
+    * The builds will fail for both the `main` and release pr because of validation rules. Follow the [release workflow](https://github.com/open-telemetry/opentelemetry-python/blob/main/RELEASING.md) for the core repo up until this same point. Change the SHAs of each PR to point at each other to get the `main` and release builds to pass.
+  * Merge the release PR.
+  * Merge the PR to main (this can be done separately from [making the release](#making-the-release))
 
 ### Preparing a major or minor release for individual package
 
@@ -62,6 +63,7 @@ The workflow can only be run against long-term release branch such as `package-r
   * Review and merge the pull request that it creates for updating the change log in main
     (note that if this is not a patch release then the change log on main may already be up-to-date,
     in which case no pull request will be created).
+  * Verify that a new [Github release](https://github.com/open-telemetry/opentelemetry-python-contrib/releases) has been created and that the CHANGELOGs look correct.
 
 ### Releasing individual package
 
@@ -79,6 +81,14 @@ to pick a specific package to release.
 
 The workflow can only be run against long-term release branch such as `package-release/{package-name}/v{major}.{minor}.x` or `package-release/{package-name}/v{major}.{minor}bx`.
 
+## After the release
+
+* Check PyPI
+  * This should be handled automatically on release by the [publish action](https://github.com/open-telemetry/opentelemetry-python-contrib/blob/main/.github/workflows/release.yml).
+  * Check the [action logs](https://github.com/open-telemetry/opentelemetry-python-contrib/actions/workflows/release.yml) to make sure packages have been uploaded to PyPI
+  * Check the release history (e.g. https://pypi.org/project/opentelemetry-instrumentation/#history) on PyPI
+  * If for some reason the action failed, see [Publish failed](#publish-failed) below
+
 ## Notes about version numbering for stable components
 
 * The version number for stable components in the `main` branch is always `X.Y.0.dev`,
@@ -110,28 +120,6 @@ The workflow can only be run against long-term release branch such as `package-r
   * The version number for unstable components in the `main` branch will be bumped to the next version,
     e.g. `0.{Y+1}b0.dev`.
 
-## After the release
-
-* Check PyPI
-  * This should be handled automatically on release by the [publish action](https://github.com/open-telemetry/opentelemetry-python-contrib/blob/main/.github/workflows/release.yml).
-  * Check the [action logs](https://github.com/open-telemetry/opentelemetry-python-contrib/actions/workflows/release.yml) to make sure packages have been uploaded to PyPI
-  * Check the release history (e.g. https://pypi.org/project/opentelemetry-instrumentation/#history) on PyPI
-  * If for some reason the action failed, see [Publish failed](#publish-failed) below
-* Move stable tag
-  * Run the following (TODO automate):
-
-    ```bash
-    git tag -d stable
-    git tag stable
-    git push --delete origin tagname
-    git push origin stable
-    ```
-
-  * This will ensure the docs are pointing at the stable release.
-  * To validate this worked, ensure the stable build has run successfully:
-    <https://readthedocs.org/projects/opentelemetry-python/builds/>.
-    If the build has not run automatically, it can be manually trigger via the readthedocs interface.
-
 ## Releasing dev version of new packages to claim namespace
 
 When a contribution introduces a new package, in order to mitigate name-squatting incidents, release the current development version of the new package under the `opentelemetry` user to simply claim the namespace. This should be done shortly after the PR that introduced this package has been merged into `main`.