Page History

...

1. Preparing release source:
   1. For a point release from a release branch (21.10.7 is the example used below):
      1. Make a source branch containing all the commits to be released, rooted on previous release commit.
      2. Open a PR into the previous release, causing it to be tested by CI. This can and should happen in advance of the release for team review. Hopefully this is the hardest part of the process.
      3. Add a final commit, that changes the version to the next one being released, usually just removing SNAPSHOT.
   2. release from mainline
      1. Make a release branch which points to the commit on main to be released.
      2. Add a final commit, that changes the version to the next one being released.
2. PR opened from the source into either a release or main branch, when merged, that is the signal to build deploy the artifacts. The release/main branch is run through the CI process.  Example https://github.com/hyperledger/besu/pull/3278
3. Let that build, and during the assembly phase artifacts the branch name will allow the publish job to run. Artifacts should be pushed to the following places:
   1. tarfile - https://hyperledger.jfrog.io/ui/native/besu-binaries/besu/21.10.7/besu-21.10.7.tar.gz
   2. zipfile - https://hyperledger.jfrog.io/ui/native/besu-binaries/besu/21.10.7/besu-21.10.7.zip
   3. PROBLEM: so far, release-like artifacts with any version number are created by the act of opening PRs, not approving them!
4. During the next build phaseDuring the dockerPublish job, the docker image is built and tagged with this release number.
   1. docker image - https://hub.docker.com/layers/hyperledger/besu/21.10.7/images/sha256-a984a8ed88931530ebe3cab02c3f1ce928c5821e8d59ad3c897a5a6e111058b8?context=explorePROBLEM: so far, release-like artifacts with any version number are created by the act of opening PRs, not approving them!
5. Theoretically, the release is done, and the versioned artifacts have been released and are all publicly available. For instance, any docker stacks running something like Watchtower, will detect a new latest build and deploy it.
6. Releaser publicizes the release by drafting a release on the github project page.
   1. Release is named after the version number.
   2. The Changelog from the Changelog file in source control is pasted into the description.
   3. Direct links to the .tar and .zip are included, as well as the corresponding SHA-256 hashes for each binary.
      • PROBLEM: if the releaser doesn't download the artifacts from the right section of artifactory (which is https://hyperledger.jfrog.io/artifactory/besu-binaries/besu/), but instead used the /ui/native/... URLs from artifactory, curl will return the intermediate hash pages and your hashes will be all wrong.
7. This will trigger even more reactions from interested automation. For instance, beaconchain watches for these releases, and sends out notifications to users who want to be updated.
8. Documentation is released - this is already tag based!
   1. https://wiki.hyperledger.org/display/BESU/Documentation+release+process
   2.  https://github.com/hyperledger/besu-docs/releases/tag/21.10.7
   3. creating the release in github, creates the tag, which triggers the release and deployment of docs to readthedocs.org
9. Homebrew release
   
   1. releaser updates besu.rb in https://github.com/hyperledger/homebrew-besu to the latest calver of the artifact, and corresponding hash.
   2. PR is opened into main.
   3. Once approved and merged, the tap is considered updated, and homebrew users will now get the configured version on update.

...