You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Let there be some set S of upstream commits, say S = {G3,G6,G8}, for which we wish the functionality to be included in libevm releases.; i.e. in all release branches, the S commits are included in the history. The difference lies in how each commit is introduced, either through:
Cherry-picking onto a release branch (never main), depicted as square commits; or
Being in the libevm history due to a merge of upstream code.
Invariants:
Cherry-picked commits are in order;
Exactly one copy of a commit, original or cherry-picked exists on a release branch; and
As a corollary of the single-version invariant: cherry-picking MUST NOT be performed on main.
Assuming S hasn't grown, creating a new release is therefore equivalent to an interactive rebase of an old release onto the tip of main. If main already includes a previously cherry-picked commit then it is dropped in the rebase, otherwise it is picked. The rebase is therefore monotonic from drop to pick because of invariant (1). If S grows then the new commits are cherry-picked after the rebase, i.f.f. necessary per invariant (2).
A single Rx commit exists at the tip of each release branch for chore changes like updating params.LibEVMVersion. These MUST be dropped during a new-release rebase.
Note
Branches release0 and release1 are graphically out of order solely to avoid confusing graph intersections.
The libevm branch is called main in the repo, but labelled differently here to ease understanding.
reacted with thumbs up emoji reacted with thumbs down emoji reacted with laugh emoji reacted with hooray emoji reacted with confused emoji reacted with heart emoji reacted with rocket emoji reacted with eyes emoji
-
Let there be some set
S
of upstream commits, sayS = {G3,G6,G8}
, for which we wish the functionality to be included inlibevm
releases.; i.e. in all release branches, theS
commits are included in the history. The difference lies in how each commit is introduced, either through:main
), depicted as square commits; orlibevm
history due to a merge of upstream code.Invariants:
main
.Assuming
S
hasn't grown, creating a new release is therefore equivalent to an interactive rebase of an old release onto the tip ofmain
. Ifmain
already includes a previously cherry-picked commit then it isdrop
ped in the rebase, otherwise it ispick
ed. The rebase is therefore monotonic fromdrop
topick
because of invariant (1). IfS
grows then the new commits are cherry-picked after the rebase, i.f.f. necessary per invariant (2).A single
Rx
commit exists at the tip of each release branch for chore changes like updatingparams.LibEVMVersion
. These MUST be dropped during a new-release rebase.Note
release0
andrelease1
are graphically out of order solely to avoid confusing graph intersections.libevm
branch is calledmain
in the repo, but labelled differently here to ease understanding.Beta Was this translation helpful? Give feedback.
All reactions