Conversation
| The `myusername/release/v1.13.14-0.2.0.rc.4` branch will be used to add "release modifications" and will target the branch `release/v1.13.14-0.2.0.rc.4` in a pull request. | ||
| 1. Run script `./cherrypick.sh` which cherry picks all Geth commits listed in [cherrypicks](cherrypicks) | ||
| - you may have to resolve conflicts | ||
| 1. Modify [params/version.libevm.go](/params/version.libevm.go) |
There was a problem hiding this comment.
It's useful to have this as the first step but NOT have anything committed. That way the version string is automatically generated for naming the release branch.
There was a problem hiding this comment.
That way the version string is automatically generated for naming the release branch.
Through a test right?
I think it's best to keep it as it is, and have the CI check on the version string humanly typed, to avoid any bad copy-paste surprises.
Co-authored-by: Arran Schlosberg <[email protected]> Signed-off-by: Quentin McGaw <[email protected]>
Co-authored-by: Arran Schlosberg <[email protected]> Signed-off-by: Quentin McGaw <[email protected]>
Co-authored-by: Arran Schlosberg <[email protected]> Signed-off-by: Quentin McGaw <[email protected]>
Co-authored-by: Arran Schlosberg <[email protected]> Signed-off-by: Quentin McGaw <[email protected]>
Co-authored-by: Arran Schlosberg <[email protected]> Signed-off-by: Quentin McGaw <[email protected]>
|
Given @ceyonur's concerns with the repeated reviews required by this release pattern we'll probably deprecate it in favour of cherry-picking to |
2 participants
Why this should be merged
The documentation was lacking on how to create a new release tag, using newer automation tools developed.
How this works
Add readme.md in libevm/tooling/release and reference it in the root readme.md
How this was tested
Following each step to create https://github.com/ava-labs/libevm/releases/tag/v1.13.14-0.2.0.rc.4