From 241befe0a083e700c08ae21e833cc8490933d9e4 Mon Sep 17 00:00:00 2001 From: Phil Ngo Date: Fri, 19 Jul 2024 18:30:17 -0400 Subject: [PATCH 1/6] Add additional instructions for hotfix --- RELEASE.md | 61 ++++++++++++++++++++++++++++++++++++++++++++++++++++-- 1 file changed, 59 insertions(+), 2 deletions(-) diff --git a/RELEASE.md b/RELEASE.md index 91b450baa34a..441c16f2c421 100644 --- a/RELEASE.md +++ b/RELEASE.md @@ -1,4 +1,4 @@ -# Lodestar Release Guidelines +∏# Lodestar Release Guidelines Lodestar is a blockchain node securing the Ethereum Beacon chain network. It is run by external individuals and operator entities outside of the control of the Lodestar team. We, as most other core dev teams, choose a slow conservative approach to releasing to ensure those node runners always update to stable, safe, and performant versions of our software. @@ -162,8 +162,65 @@ Tagging a release candidate will trigger CI to publish to NPM, dockerhub, and Gi - `git tag -am "v1.1.1-rc.0" v1.1.1-rc.0` - `git push origin v1.1.1-rc.0` -Continue following the "test release candidate" and "merge release candidate" sections. Testing window may be modified depending on the severity of the bug fixed. +### 3. Test hotfix release candidate +Once a hotfix release candidate is created, the Lodestar team may begin a modified hotfix testing period consisting of a quick sanity check or longer if required. + +If the hotfix does not address the purpose of the hotfix release, or there is another bug discovered during this modified hotfix testing period which significantly impacts performance, security, or stability, and it is determined that it is no longer prudent to promote the `rc.x` candidate to `stable`, then it will await an additional fix by the team. The fix will be committed to `unstable` first, then cherrypicked into the `rc/v1.1.1` hotfix branch. Then we publish and promote the new commit to `rc.x+1`. The modified hotfix testing period will reset. + +For example: After modified hotfix testing period, is the original bug resolved? Is performance equal to or better than latest stable? + +- **Yes**: Continue to the next release step +- **No**: If it a small issue fixable quickly with another hot-fix? + - **Yes**: Merge fix(es) to `unstable`, push the fix(es) to `rc/v1.1.1` hotfix branch, go to step 2, incrementing the rc version + - **No**: Abort the release. Close the `chore: v1.1.v release` PR, delete the branch, and start the whole release process over. + +### 4. Merge hotfix release candidate + +- Ensure step 3 testing is successful and there is sufficient consensus to release `v1.1.1`. +- Approving the `chore: v1.1.1 release` PR means a team member marks the release as safe, after personally reviewing and / or testing it. +- Merge `chore: v1.1.1 release` PR to stable **with "merge commit"** strategy to preserve all history. +- Merge stable `stable` into `unstable` **with merge commit** strategy. Due to branch protections in `unstable` must open a PR. If there are conflicts, those must be resolved manually. Gitflow may cause changes that conflict between stable and unstable, for example due to a hotfix that is backported. If that happens, disable branch protections in unstable, merge locally fixing conflicts, run lint + tests, push, and re-enable branch protections. See "Backporting merge conflicts from stable to unstable". + +#### Backporting merge conflicts from stable to unstable +This process is unusual and if you discover that `stable` has unwanted changes from `unstable` in the release commit, you can undo the most recent commit and reset the working directory and index to match the state of the repository at the previous commit using: +- `git reset --hard HEAD~1` +- `git push -f` + +Pull the latest commits on both `stable` and `unstable` branches: +- `git checkout stable && git pull origin stable` +- `git checkout unstable && git pull origin unstable` + +Merge `stable` into `unstable` with conflict resolutions: +- `git checkout unstable && git merge stable` +- Resolve conflicts +- Sanity check locally before pushing by using: `git diff unstable origin/unstable` +- Disable `unstable` branch protection +- `git push` +- Enable `unstable` branch protection + +### 5. Tag stable release + +Tagging a stable release will trigger CI to publish to NPM, dockerhub, and Github releases. + +#### All-in-one script (for example version `v1.1.0`): + +- `git checkout stable` +- `yarn release:tag-stable 1.1.0` + - Must be run locally from a write-access account capable of triggering CI. + +#### Manual steps (for example version `v1.1.0`): + +- Check out the new stable + - `git checkout stable` +- Tag it as `v1.1.0` with an annotated tag, push commit and tag. + - `git tag -am "v1.1.0" v1.1.0` + - `git push origin v1.1.0` + +### 6. Announce + +- Double check that Github release is correct +- Publish to Social Media ## Dev release On every commit to `unstable` a dev release is done automatically in CI. A dev release: From aaf19239dad4e13bfb42c1b01c469ba939b60a53 Mon Sep 17 00:00:00 2001 From: Phil Ngo <58080811+philknows@users.noreply.github.com> Date: Mon, 22 Jul 2024 10:46:58 -0400 Subject: [PATCH 2/6] fix merge conflict title Co-authored-by: Cayman --- RELEASE.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/RELEASE.md b/RELEASE.md index 441c16f2c421..d22526fce561 100644 --- a/RELEASE.md +++ b/RELEASE.md @@ -182,7 +182,7 @@ For example: After modified hotfix testing period, is the original bug resolved? - Merge `chore: v1.1.1 release` PR to stable **with "merge commit"** strategy to preserve all history. - Merge stable `stable` into `unstable` **with merge commit** strategy. Due to branch protections in `unstable` must open a PR. If there are conflicts, those must be resolved manually. Gitflow may cause changes that conflict between stable and unstable, for example due to a hotfix that is backported. If that happens, disable branch protections in unstable, merge locally fixing conflicts, run lint + tests, push, and re-enable branch protections. See "Backporting merge conflicts from stable to unstable". -#### Backporting merge conflicts from stable to unstable +#### Fixing merge conflicts from stable to unstable This process is unusual and if you discover that `stable` has unwanted changes from `unstable` in the release commit, you can undo the most recent commit and reset the working directory and index to match the state of the repository at the previous commit using: - `git reset --hard HEAD~1` - `git push -f` From 70d3d1337884af020a08ac584862d6a23c50a679 Mon Sep 17 00:00:00 2001 From: Phil Ngo <58080811+philknows@users.noreply.github.com> Date: Mon, 22 Jul 2024 10:47:45 -0400 Subject: [PATCH 3/6] resolving conflicts Co-authored-by: Cayman --- RELEASE.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/RELEASE.md b/RELEASE.md index d22526fce561..e440821c4018 100644 --- a/RELEASE.md +++ b/RELEASE.md @@ -191,7 +191,7 @@ Pull the latest commits on both `stable` and `unstable` branches: - `git checkout stable && git pull origin stable` - `git checkout unstable && git pull origin unstable` -Merge `stable` into `unstable` with conflict resolutions: +Merge `stable` into `unstable`, resolving conflicts: - `git checkout unstable && git merge stable` - Resolve conflicts - Sanity check locally before pushing by using: `git diff unstable origin/unstable` From 60a28a405d20ba7d5d6ca99be5957a0c89faf8d4 Mon Sep 17 00:00:00 2001 From: Phil Ngo Date: Mon, 22 Jul 2024 11:00:10 -0400 Subject: [PATCH 4/6] minor fixes addressed --- RELEASE.md | 20 ++++++++------------ 1 file changed, 8 insertions(+), 12 deletions(-) diff --git a/RELEASE.md b/RELEASE.md index e440821c4018..1a8b3aaab449 100644 --- a/RELEASE.md +++ b/RELEASE.md @@ -182,11 +182,6 @@ For example: After modified hotfix testing period, is the original bug resolved? - Merge `chore: v1.1.1 release` PR to stable **with "merge commit"** strategy to preserve all history. - Merge stable `stable` into `unstable` **with merge commit** strategy. Due to branch protections in `unstable` must open a PR. If there are conflicts, those must be resolved manually. Gitflow may cause changes that conflict between stable and unstable, for example due to a hotfix that is backported. If that happens, disable branch protections in unstable, merge locally fixing conflicts, run lint + tests, push, and re-enable branch protections. See "Backporting merge conflicts from stable to unstable". -#### Fixing merge conflicts from stable to unstable -This process is unusual and if you discover that `stable` has unwanted changes from `unstable` in the release commit, you can undo the most recent commit and reset the working directory and index to match the state of the repository at the previous commit using: -- `git reset --hard HEAD~1` -- `git push -f` - Pull the latest commits on both `stable` and `unstable` branches: - `git checkout stable && git pull origin stable` - `git checkout unstable && git pull origin unstable` @@ -199,28 +194,29 @@ Merge `stable` into `unstable`, resolving conflicts: - `git push` - Enable `unstable` branch protection -### 5. Tag stable release +### 5. Tag stable hotfix release Tagging a stable release will trigger CI to publish to NPM, dockerhub, and Github releases. -#### All-in-one script (for example version `v1.1.0`): +#### All-in-one script (for example version `v1.1.1`): - `git checkout stable` -- `yarn release:tag-stable 1.1.0` +- `yarn release:tag-stable 1.1.1` - Must be run locally from a write-access account capable of triggering CI. -#### Manual steps (for example version `v1.1.0`): +#### Manual steps (for example version `v1.1.1`): - Check out the new stable - `git checkout stable` -- Tag it as `v1.1.0` with an annotated tag, push commit and tag. - - `git tag -am "v1.1.0" v1.1.0` - - `git push origin v1.1.0` +- Tag it as `v1.1.1` with an annotated tag, push commit and tag. + - `git tag -am "v1.1.1" v1.1.1` + - `git push origin v1.1.1` ### 6. Announce - Double check that Github release is correct - Publish to Social Media + ## Dev release On every commit to `unstable` a dev release is done automatically in CI. A dev release: From 13c1ad58c429b438418775f2bf002a9beda21454 Mon Sep 17 00:00:00 2001 From: Phil Ngo Date: Fri, 26 Jul 2024 10:08:05 -0400 Subject: [PATCH 5/6] address comments --- RELEASE.md | 18 +++++++++--------- 1 file changed, 9 insertions(+), 9 deletions(-) diff --git a/RELEASE.md b/RELEASE.md index 1a8b3aaab449..53244cc3d2ce 100644 --- a/RELEASE.md +++ b/RELEASE.md @@ -1,4 +1,4 @@ -∏# Lodestar Release Guidelines +# Lodestar Release Guidelines Lodestar is a blockchain node securing the Ethereum Beacon chain network. It is run by external individuals and operator entities outside of the control of the Lodestar team. We, as most other core dev teams, choose a slow conservative approach to releasing to ensure those node runners always update to stable, safe, and performant versions of our software. @@ -74,7 +74,7 @@ If there is a bug discovered during the testing period which significantly impac For example: After 3-5 days of testing, is performance equal to or better than latest stable? - **Yes**: Continue to the next release step -- **No**: If it a small issue fixable quickly (hot-fix)? +- **No**: If it a small issue fixable quickly (hotfix)? - **Yes**: Merge fix(es) to `unstable`, push the fix(es) to `rc/v1.1.0` branch, go to step 2, incrementing the rc version - **No**: abort the release. Close the `chore: v1.1.0 release` PR, delete the branch, and start the whole release process over. @@ -106,11 +106,11 @@ Tagging a stable release will trigger CI to publish to NPM, dockerhub, and Githu ### 6. Announce - Double check that Github release is correct -- Publish to Social Media +- Follow [Publish to Social Media](#publish-to-social-media) steps -## Hot-fix release +## Hotfix release -If a stable version requires an immediate hot-fix before the next release, a hot-fix release is started. +If a stable version requires an immediate hot-ix before the next release, a hotfix release is started. A similar process for a stable release is used, with the three differences. @@ -171,7 +171,7 @@ If the hotfix does not address the purpose of the hotfix release, or there is an For example: After modified hotfix testing period, is the original bug resolved? Is performance equal to or better than latest stable? - **Yes**: Continue to the next release step -- **No**: If it a small issue fixable quickly with another hot-fix? +- **No**: If it a small issue fixable quickly with another hotfix? - **Yes**: Merge fix(es) to `unstable`, push the fix(es) to `rc/v1.1.1` hotfix branch, go to step 2, incrementing the rc version - **No**: Abort the release. Close the `chore: v1.1.v release` PR, delete the branch, and start the whole release process over. @@ -180,7 +180,7 @@ For example: After modified hotfix testing period, is the original bug resolved? - Ensure step 3 testing is successful and there is sufficient consensus to release `v1.1.1`. - Approving the `chore: v1.1.1 release` PR means a team member marks the release as safe, after personally reviewing and / or testing it. - Merge `chore: v1.1.1 release` PR to stable **with "merge commit"** strategy to preserve all history. -- Merge stable `stable` into `unstable` **with merge commit** strategy. Due to branch protections in `unstable` must open a PR. If there are conflicts, those must be resolved manually. Gitflow may cause changes that conflict between stable and unstable, for example due to a hotfix that is backported. If that happens, disable branch protections in unstable, merge locally fixing conflicts, run lint + tests, push, and re-enable branch protections. See "Backporting merge conflicts from stable to unstable". +- Merge `stable` into `unstable` **with merge commit** strategy. Due to branch protections in `unstable` must open a PR. If there are conflicts, those must be resolved manually. Gitflow may cause changes that conflict between stable and unstable, for example due to a hotfix that is backported. If that happens, disable branch protections in unstable, merge locally fixing conflicts, run lint + tests, push, and re-enable branch protections. See "Backporting merge conflicts from stable to unstable". Pull the latest commits on both `stable` and `unstable` branches: - `git checkout stable && git pull origin stable` @@ -215,7 +215,7 @@ Tagging a stable release will trigger CI to publish to NPM, dockerhub, and Githu ### 6. Announce - Double check that Github release is correct -- Publish to Social Media +- Follow [Publish to Social Media](#publish-to-social-media) steps ## Dev release @@ -333,7 +333,7 @@ Lodestar used `master` as the single target for feature branches. - QA is done on `v1.1.x` branch - Fixes on rc are done on `v1.1.x`, then re-tag - Once released final `v1.1.0` tag is on a branch that is never merged -- Hot-fixes are either cherry-picked from `master` or done on the `v1.1.x` branch, never merged +- Hotfixes are either cherry-picked from `master` or done on the `v1.1.x` branch, never merged However, this had some issues: From 17b61dbaa6d9823a29c5d38321baadd24508194f Mon Sep 17 00:00:00 2001 From: Phil Ngo <58080811+philknows@users.noreply.github.com> Date: Sun, 28 Jul 2024 14:46:43 -0400 Subject: [PATCH 6/6] spelling fix Co-authored-by: Nico Flaig --- RELEASE.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/RELEASE.md b/RELEASE.md index 53244cc3d2ce..ad96c918a1b5 100644 --- a/RELEASE.md +++ b/RELEASE.md @@ -110,7 +110,7 @@ Tagging a stable release will trigger CI to publish to NPM, dockerhub, and Githu ## Hotfix release -If a stable version requires an immediate hot-ix before the next release, a hotfix release is started. +If a stable version requires an immediate fix before the next release, a hotfix release is started. A similar process for a stable release is used, with the three differences.