Adjust vulnerability runbook to not open PR version bumps (#11919)

Historically this was needed to give some time to figure out CI issues,
if any. Nowadays though we test all release branches weekly to ensure
their CI is running so any failures should be at most a week old. Given
that there's no need to open version bumps ahead of time. This also
avoids leaking information in advance disclosure about affected versions
which narrows the range of the where the bug could be.

Author: alexcrichton

docs/security-vulnerability-runbook.md

@@ -64,33 +64,34 @@ is created these steps are followed:
    it, and that's ok, but try to get the ones that may have common failures.
    This is required because CI doesn't run on private forks.
 
-10. **Open version bump PRs on the public repository**. Use the [online trigger]
-    for this workflow to open PRs for all versions that are going to be patched.
-    DO NOT include patch notes or release notes for this fix. Use this time to
-    fix CI by landing PRs to the release branches separate from the version bump
-    PR. DO NOT merge the version bump PR.
+10. **Release day: Open version bump PRs on the public repository**. Use the
+    [online trigger] for this workflow to open PRs for all versions that are
+    going to be patched. Patch notes should be included with the private PRs, so
+    no need to worry about that. Plan on merging these PRs after the PRs below
+    are merged. Note that CI should be green as we test that it's green weekly
+    for all supported branches, but if it's not you'll need to fix that.
 
 [online trigger]: https://github.com/bytecodealliance/wasmtime/actions/workflows/release-process.yml
 
-11. **Manually make PRs on release day**. DO NOT merge via the security
-    advisory. This has generally not worked well historically because there's
-    too many CI failures and branch protections. On the day of the release make
-    public PRs from all of the previously-created PRs on the private fork.
-    You'll need to push the changes to your own personal repository for this,
-    but that's ok since it's time to make things public anyway. Merge all PRs
-    (including to `main`) once CI passes.
-
-12. **Merge version bump PRs**. Once the fixes have all been merged and CI is
-    green merge all the version bump PRs. That will trigger the automatic
-    release process which will automatically publish to crates.io and publish
-    the release.
-
-13. **Publish the GitHub Advisories**. Delete the private forks and hit that Big
-    Green Button to publish the advisory.
-
-14. **Send mail about the security release**. Send another around of mail to
-    [email protected] describing the security release. This mail
-    looks [like
+11. **Release day: Manually make PRs to affected branches**. DO NOT merge via
+    the security advisory. This has generally not worked well historically
+    because there's too many CI failures and branch protections. On the day of
+    the release make public PRs from all of the previously-created PRs on the
+    private fork. You'll need to push the changes to your own personal
+    repository for this, but that's ok since it's time to make things public
+    anyway. Merge all PRs (including to `main`) once CI passes.
+
+12. **Release day: Merge version bump PRs**. Once the fixes have all been merged
+    and CI is green merge all the version bump PRs. That will trigger the
+    automatic release process which will automatically publish to crates.io and
+    publish the release.
+
+13. **Release day: Publish the GitHub Advisories**. Delete the private forks and
+    hit that Big Green Button to publish the advisory.
+
+14. **Release day: Send mail about the security release**. Send another around
+    of mail to [email protected] describing the security
+    release. This mail looks [like
     this](https://groups.google.com/a/bytecodealliance.org/g/sec-announce/c/7SjEU_qSE4U/m/zjW9fWlcAAAJ).
 
 14. **Add the advisory to the [RustSec