Merge branch 'fix/2771' of github.com:blockstack/stacks-blockchain in…

…to fix/2771

README.md

@@ -329,7 +329,24 @@ cargo fmt --all
 
 For non-consensus breaking releases, this project uses the following release process:
 
-1. A release manager enumerates the PRs or issues that would _block_
+1. The release must be timed so that it does not interfere with a *prepare
+phase*.  The timing of the next Stacking cycle can be found
+[here](https://stacking.club/cycles/next). A release to `mainnet` should happen
+at least 24 hours before the start of a new cycle, to avoid interfering
+with the prepare phase. So, start by being aware of when the release can
+happen.
+
+1. Before creating the release, the release manager must determine the *version
+number* for this release.  The factors that determine the version number are
+discussed in [Versioning](#versioning).  We assume, in this section,
+that the change is not consensus-breaking.  So, the release manager must first
+determine whether there are any "non-consensus-breaking changes that require a
+fresh chainstate". This means, in other words, that the database schema has
+changed. Then, the release manager should determine whether this is a feature
+release, as opposed to a hot fix or a patch. Given the answers to these
+questions, the version number can be computed.
+
+1. The release manager enumerates the PRs or issues that would _block_
    the release. A label should be applied to each such issue/PR as
    `2.0.x.y.z-blocker`. The release manager should ping these
    issue/PR owners for updates on whether or not those issues/PRs have
@@ -339,6 +356,16 @@ For non-consensus breaking releases, this project uses the following release pro
    all the blocker PRs have merged, as it is helpful for the manager and others
    to see the staged changes.
 
+1. The release manager must update the `CHANGELOG.md` file with summaries what
+was `Added`, `Changed`, and `Fixed`. The pull requests merged into `develop`
+can be found
+[here](https://github.com/blockstack/stacks-blockchain/pulls?q=is%3Apr+is%3Aclosed+base%3Adevelop+sort%3Aupdated-desc). Note, however, that GitHub apparently does not allow sorting by
+*merge time*, so, when sorting by some proxy criterion, some care should
+be used to understand which PR's were *merged* after the last `develop ->
+master` release PR.  This `CHANGELOG.md` should also be used as the description
+of the `develop -> master` so that it acts as *release notes* when the branch
+is tagged.
+
 1. Once the blocker PRs have merged, the release manager will create a new tag
    by manually triggering the [`stacks-blockchain` Github Actions workflow](https://github.com/blockstack/stacks-blockchain/actions/workflows/stacks-blockchain.yml)
    against the `develop` branch, inputting the release candidate tag, `2.0.x.y.z-rc0`,