...
- main should always be release-able
- a chain of commits in the release branch from main provide provenance of a release
- the ability to merge PRs into main is uninhibited by the release process, and the release process itself is not encumbered by changes to main
- the RC process provides a crisp delineation of burn-in build artifacts and final release artifacts
Example Release Workflow for HL Besu 23.7.3
...
- Create a release candidate PR which merges `main` into the `release` branch, which also updates the build version to reflect 23.7.3-RC
- Upon merge into the release branch, CI builds and publishes the necessary artifacts for the release candidate
- Deploy canary and burn-in builds with the published release candidate artifacts
- Create a PR against main to bump the build version and add a new version section to CHANGELOG.md to reflect the next snapshot revision
- Upon successful validation of the release candidate burn-in:
- create a PR against the release branch to update ONLY the build version to 23.7.3, removing the -RC suffix
- upon successful build and merge of the release PR:
- draft a new github release for 23.7.3
- wait for docker artifacts to build and publish
- publish the github release with artifact SHAs and announce on HL discord
...