You are viewing an old version of this page. View the current version.

Compare with Current View Page History

Version 1 Next »

During the August 4th Contributor Call, Besu's release process was discussed. 

Over the past few months, every Besu release has required a release candidate (see the original proposal). This change was implemented at a time where Besu releases had run into several showstopper bugs. 
Since then, things have stabilized. Since June, there hasn't been a bug found in a Besu RC requiring we scrub or re-do the release. 

In order to streamline the release process, on the last contributor call, we agreed to the following proposal:

Bi-Weekly Releases:  

  • No RC, release directly off master branch
  • Before the release is promoted by contributors' organizations, we recommend they:
    • Run it for 24 hours against the Ethereum mainnet network at the head of the chain, and;
    • Complete a fast sync from scratch against one of the major Ethereum testnets (i.e. Ropsten). 
  • If issues are found with the release during this process, we:
    • Scrub the release
      • Specifically, we recommend people not use it and stop promoting it 
      • Have the next release on an incremented version (i.e. if the scrubbed release is 1.1.1, the next one should still be 1.1.2)

Quarterly Releases:  

  • We cut RCs off a separate branch.
    • We aim to have two RCs before a quarterly release to allow bug fixes from RC1 to be included in RC2. 
  • Before the release is promoted by contributors' organizations, we recommend they:
    • Run it for 48 hours against the Ethereum mainnet network at the head of the chain, and;
    • Complete a fast sync from scratch against the Ethereum mainnet. 
  • No labels