...
- Proposal: Avoid Cherry Picked Releases
- Proposal: Quarterly releases from main by default
- Proposal: Create a Release Candidate for every release
The gist of this proposal is that we always release besu from a release branch, and that release branch only pulls commits from main.
Principles and Benefits
- 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
...
This process leaves a cherry-pick escape hatch for hotfixes that is minimum friction for the latest release at least. The biggest element of friction here is the PR which merges main into the release would need to handle the merge conflict that a cherry-pick creates. This implies that it would be desirable for cherry-picking should to be a rare event, that is done with care.
Currently Trialing this process with 23.7.x
We have been trialing this process for the 23.7.x series of releases, and have encountered essentially all of the scenarios described above. 23.7.0 was a simple merge of main into a new release branch. However, 23.7.0 failed burn-in, and 23.7.1 was a fast-follow cherry-pick release. 23.7.2 had to account for this cherry pick and the PR to merge main was higher than desired friction. 23.7.3 should be another low friction release. In all of these, `main` branch development was unimpeded and the release process was not affected by it.
...