Road to Stability

[q9f]

We currently to nightly "unstable" releases and biweekly "alpha" releases, however, at this early stage of the project, we do not have any strategies towards stabilizing the code and the releases.

I use this meta ticket to outline some strategies to revisit in future in case we want to move into a "beta" or "stable" phase.

Useful resouce:

• https://hackmd.io/HOaKGHWGT-aLzF6kh1KQfA
• I had this call with the Teku, Lighthouse, and Prysm teams last year
• Everything in this document also applies to Lodestar obviously

The key element is the release checklist (we can already tick two boxes):

Release components checklist for teams:

• dedicate a team member to commit to releases (release manager, release coordinator) --> @q9f?
• commit to a strict versioning scheme (semver, calver, etc.) --> semver (lerna)
• enable concurrent development that reflect different expectations of release quality (stable, beta, nightly, etc.)
• conduct pre-release testing (release candidates, CI, QA)
• distribute packages (binaries, signatures, checksums) --> NPM/Docker

The hackmd above also outlines two different release strategies (Flow vs. Maturity). I always give the example that Geth uses the "Flow" strategy and Parity uses used "Maturity." I'm personally a big fan of the latter.

Current State of Lodestar https://github.com/ChainSafe/lodestar/releases

• has development branches
  • master (pull requests default to master)
• has releases (23)
  • v0.29.1 on ⚠️ master
  • v0.29.0 on ⚠️ master
  • ...
• ⚠️ has release branches
  • ⚠️ no release branch for current track (0.29 ?)

[dapplion]

Spoke with Afri and got a good plan that should be relatively easy to follow tho it requires non-trivial changes to our CI.

This diagram explains the process for the first release going into this flow (v0.33.0 release), and a regular release already being into this flow (v0.34.0 release)

This git flow allows us to:

• Branch a potential release into a "candidate" stage while we test for 3 or more days
• Commit bug fixes exclusively to that release candidate, and preserve separation from master such that we can keep merging unstable PRs to master
• Easily promote that commit to stable release

Changes to do (at least)

• CI must not trigger release on package.json bump, but on a tag
• Bump master to the next version when creating a release candidate

[twoeths]

this looks great to me, once we create a branch for a release we should have docker image for that release and assign someone (or the release manager?) to deploy/test it for 3-4 days before it becomes stable.

[g11tech]

lgtm OK 👍

[dapplion]

v0.33.0 todo

• Update release workflow Trigger release with tag push #3504
• Bump master to v0.33.0 + tag as v0.33.0-beta.0
• Bump master to v0.34.0 and develop new features there

[philknows]

I think we're ready to close this epic unless there are any other outstanding issues with the release process @dapplion .

[dapplion]

I think we're ready to close this epic unless there are any other outstanding issues with the release process @dapplion .

Yes ready to be closed. However I think we should persist this information somewhere, any ideas?

[philknows]

I think we're ready to close this epic unless there are any other outstanding issues with the release process @dapplion .

Yes ready to be closed. However I think we should persist this information somewhere, any ideas?

Maybe a releases.md in the main directory?

[q9f]

🎉