Versions Compared

Old Version 4

changes.mady.by.user Simon Dudley

Saved on

compared with

New Version Current

changes.mady.by.user Justin Florentine

Saved on

Key

  • This line was added.
  • This line was removed.
  • Formatting was changed.

This is an aggregation of three proposed release strategies:

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
  • cherry-picking commits to compose a release remains possible, if discouraged

Example Release Workflow for a hypothetical HL Besu

...

24.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. 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
      1. This prevents blocking main during the release but creates a bookmark to indicate that the release will include up to the commit before this.
    3. Create a release candidate PR which merges `main` as of the release point into the `release-<version>` branch.
    4. When release branch exists and is tagged, any pre-release activities may commence. This usually includes executing a long-running (about 48 hours) "burn in" process which deploys new nodes to sync from scratch on a variety of networks, using a variety of CL clients.
    5. At this point, there is no published artifact, and testing may take as long as deemed necessary.

    Final release steps (Day X)

    Upon successful validation of the release candidate burn-in:

    1. Define a new release on GitHub using the <version> for the release.
      1. draft a new github release for <version>
      2. publish the github release and announce on HL discord. This will create a new release and all artifacts will be versioned based on the string in the name of the release.
      3. build artifacts will be attached to the release, and accurate SHAs and docker locations will be amended.
    2. Trigger release process for documentation - Documentation release process
    3. Homebrew release

    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

    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.


    Comments, feedback, and clarification are all welcome.