# Besu Tag-based Release in GAR-e

### Branch Based Releases (commit.py)
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>, 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>-SNAPSHOT).

Lastly, this process requires at least 2 contributors to complete the release process because 2 rounds of PR approvals are necessary to proceed. This may or may not be a feature, more on this later.

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.

### Tag Releases (tag.py)
#### Overhead savings
Tag releases are commit based rather than branch HEAD based. When releasing from master, there is no branch management, PRs or approval required to release. There will be a single build of the release tag by circle-ci. The release process is hands-off and automated all the way up to the release on github. This is a substantial time savings and much lower friction compared to the branch based release strategy.

#### Release approval
In addition to the time savings, there is a lower bar to releasing. A single contributor can do a release since there are no PR approvals required. This is arguable if it is a benefit or not, since a single contributor could ‘go rogue’. I think this risk exists already, the difference is that we would normalize single contributor signoff for releases.

#### Deficiencies compared to branch releases
The branch based release strategy works well with the quarterly release flow for besu. The branch logic “recognizes” a release branch by naming convention and increments the artifact version correctly for release candidates and final versions. Also the branch flow deletes the long-lived release branch upon release of a final quarterly (x.y.0) release The tag flow does not have any provision for quarterly or release candidate flows. IMO, this can be worked around manually by the deployer, or quarterly release behavior could be added as a config to the tag flow without too much effort.

The primary post-deployment difference between the existing tag and branch based release flows is snapshot versioning for interim builds. The existing tag flow does not push a subsequent PR to change the release version to <semver>-SNAPSHOT at the end of the process. While this means that an additional contributor is not necessary for post-deployment, it also means that interim builds will have a common or static name like `besu-develop`. This is an artifact of the no-PR approach of this release flow. Again I think this is not terribly difficult to add as a configurable behavior to the existing tag flow. Alternatively, we could invest effort into a dynamic version calculation build function, though the mechanism for determining the current snapshot version is not straightforward when we are not on a tagged commit.

#### Migration Strategy

##### Tag flow as-is (WIP)
To migrate to tag based deployment as-is besu would:
modify projects.py to specify “release_type”: “tag”
account for tag versions in filters for .circleci/config.yml
similar to teku, implement calculateVersion and calculatePublishVersion functions in besu’s build.gradle
for quarterly release branches, manually maintain a release branch and cut RC branches (since when releasing from tag versions, the flow deletes the branch being released if it is not master)
manually manage CHANGELOG.md and versions in gradle.properties

##### With minor tag flow modifications (WIP)
automated submission of post-deployment CHANGELOG.md (and project version?) PRs
quarterly release support and recognition of `release-` branch prefixes and RC# release tags
similar to branch flow, do not delete release branches on RC releases
Final quarterly releases delete the branch and handle next build version appropriately