...
- Remove dependency on any proprietary build tools.
- Require at least 2 people to approve a release.
- Reduce possibility for error during the build process.
- Continue CalVer version numbering scheme.
Status Quo
Besu currently does branch based release strategy. Regardless of the branch being released from, during a release a new release branch is created and pushed to origin. This triggers an additional (arguably unnecessary) build PR for the merge back to the “releasing branch” (master, release-<semver><calver>, etc). It also forces a “quiet period” where we do not / cannot merge to the branch-to-release. The branch based flow also submits an additional post-release PR to merge the next project version property (so that build artifacts are <next-semver>calver>-SNAPSHOT).
Lastly, this process requires at least 2 contributors to complete the release process because 2 rounds of PR approvals are necessary to proceed. The requirement for more than one person to participate is an important feature of this process which we want to preserve.
Overall, the branch flow requires 3 CI builds and 2 PR approvals to complete a release. It seems that this flow was built to support quarterly releases, but was generalized for regular releases also.
Perfect Scenario
Any 2 authorized individuals (TBD) can inspect a proposed release candidate, and upon approval the binary goes unchanged into the GitHub release page, and any other supported artifact distribution systems.
- Releaser has easy to find changelog to review.
- Releaser has easy to find PR that shows changes from previous release for closer inspection.
- Documentation changes?
- One-click-execution?
- Audit trail?
Tag Releases
Overhead savings
...