Content Comparison

...

1. Create a PR against main to bump the build version to 24.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 include up to the commit before this.This also prevents later releases colliding with release numbers used on a disposable, release branch.
2. Create a release candidate PR which merges `main` into the `release` branch, which also updates the build version to reflect 24.7.3-RC1
   1. During the actual 24.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 24.7.4-SNAPSHOT
   as of the release point into the `release-<version>` branch.
3. 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.
4. At this point, there is no published artifact, and testing may take as long as deemed necessary.

...

Upon successful validation of the release candidate burn-in:

1. create Define a PR against the release branch to update ONLY the build version to 24.7.3, removing the -RC suffixupon successful build and merge of the release PR:new release on GitHub using the <version> for the release.
   1. draft a new github release for 24.7.3<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

...