Releasing a new rbuilder version

Summary

1. Decide on the target version number (i.e. v0.7.0)
2. (optional) Create an issue tracking the release (if needed to announce/communicate early on, and if release is not trivial)
3. Create a release branch (and PR)
4. Create a release candidate tag (v0.7.0-rc1)
5. Build, test and deploy the release candidate
6. If needed, iterate on the release candidates
7. Once satisfied, update Cargo.toml with final release version, and merge the release branch
8. Create the final release tag (v0.7.0)
9. CI prepares the binaries and draft release. Manually edit it and make it nice! (this is a product announcement, and sent out to all subscribers by email!)
10. Publish the Github release

What makes great release notes:

• Emphasize the highlights
• Note any breaking changes
• Add examples and screenshots
• Link to relevant documentation
• Link to the associated issue thread
• For bigger releases, break into sections (at least: "new features", "improvements", "bug fixes", "dependency updates")
• Important: Credit your contributors! (contributors should be acknowledged for every entry, and new contributors should be especially celebrated)
• See also: https://simonwillison.net/2022/Jan/31/release-notes/
• Good reference release notes:
  • https://github.com/flashbots/mev-boost/releases
  • https://github.com/flashbots/mev-boost-relay/releases
  • https://github.com/simonw/datasette/releases
  • https://docs.djangoproject.com/en/4.0/releases/4.0/
  • https://github.com/paradigmxyz/reth/releases/tag/v0.2.0-beta.8

---

First of all, decide on a new target version number (i.e. v0.7.0).

---

Create an issue tracking the release (if needed):

https://github.com/flashbots/rbuilder/issues/new?title=Release%20v0.7.0

That issue can be used to track and communicate the plan and overall progress.

---

Create a release/v0.7.0 branch (and pull request):

git checkout -b release/v0.7.0

---

Start by creating the first release candidate version (v0.7.0-rc1):

• Update the version number in Cargo.toml
• Commit, and tag the release candidate version

git commit -am "Release v0.7.0-rc1"
git tag -s v0.7.0-rc1
git push origin v0.7.0-rc1

This will trigger the release CI, which creates a draft release.

Open a Pull Request for the release branch.

---

Build, test and deploy the release candidate. It should run at least 24h in production before deciding to promote it to a final release.

---

After successfully testing the release candidate, create a final release tag (v0.7.0):

1. Update the version number in Cargo.toml
2. Merge the PR
3. Create the final version tag

   git tag -s v0.7.0
   git push origin v0.7.0

4. Push the tag to the repository
5. Release CI will run to build the binaries and Docker image, and to create a draft release on GitHub. See the CI output for a direct link.
6. Manually prepare nice release notes (they are a product announcement, and sent out to all subscribers by email!)
7. Publish