Page History

...

Example Release Workflow for HL Besu 23.7.3

Burn-in candidate release steps (Day 0)

1. Create a PR against main to bump the build version to 23.7.4-SNAPSHOT and add a new version section to CHANGELOG.md to reflect the next snapshot revision
   1. This prevents blocking main during the release but creates a bookmark to indicate that the release will up to the commit before this.
2. Create a release candidate PR which merges `main` into the `release` branch, which also updates the build version to reflect 23.7.3-RC
   1. During the actual 23.7.3 release, it became clear that the only way to do this nicely is by cherry-picking the commit range from main onto the release branch, e.g. git cherry-pick 6dc10a9..eef40bd 
   2. Due to 1, we need to use a subset of main commits, not including the bump to 23.7.4-SNAPSHOT
3. Upon merge into the release branch, CI builds and publishes the necessary artifacts for the release candidate
4. Deploy canary and burn-in builds with the published release candidate artifacts

Final release steps (Day X)

Upon successful validation of the release candidate burn-in:

1. create a PR against the release branch to update ONLY the build version to 23.7.3, removing the -RC suffix
2. upon successful build and merge of the release PR:
   1. draft a new github release for 23.7.3
   2. wait for docker artifacts to build and publish
   3. publish the github release with artifact SHAs and announce on HL discord
3. Trigger release process for documentation - Documentation release process

Burn-in failures and hotfixes

An alternate outcome where the burn-in fails is a no-op.  Nothing needs to happen except the same process to build a new release candidate with a new version.  We skip 23.7.3, note in CHANGELOG.md that it failed burn-in, and move on to 23.7.4.to 'cancel the release'.   We can either skip this release version (and note that outcome in CHANGELOG.md), or build an RC2 candidate by restarting the burn-in candidate steps at step #2 with the new RC number.  

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

...