One upgrade issue is building all of Electron with a single copy of V8 to ensure compatibility. This is important because upstream Node and libchromiumcontent both use their own versions of V8.
Upgrading Node is much easier than upgrading libchromiumcontent, so fewer conflicts arise if one upgrades libchromiumcontent first, then chooses the upstream Node release whose V8 is closest to it.
Electron has its own Node fork with modifications for the V8 build details mentioned above and for exposing API needed by Electron. Once an upstream Node release is chosen, it's placed in a branch in Electron's Node fork and any Electron Node patches are applied there.
Another factor is that the Node project patches its version of V8. As mentioned above, Electron builds everything with a single copy of V8, so Node's V8 patches must be ported to that copy.
Once all of Electron's dependencies are building and using the same copy of V8, the next step is to fix any Electron code issues caused by the Node upgrade.
[FIXME] something about a Node debugger in Atom that we (e.g. deepak) use and need to confirm doesn't break with the Node upgrade?
So in short, the primary steps are:
electron/nodehas updated release tags from
electron-node-vX.X.Xwhere the base that you're branching from is the tag for the desired update
vX.X.XMust use a version of node compatible with our current version of chromium
Cherry-pick commit range:
git cherry-pick FIRST_COMMIT_HASH..LAST_COMMIT_HASH
Resolve merge conflicts in each file encountered, then:
git add <conflict-file>
git cherry-pick --continue
We need to generate a patch file from each patch applied to V8.
$ git clone https://github.com/electron/libchromiumcontent
script/updateto get the latest libcc
patches/v8/README.mdto see which patchfiles were created during the last update
Remove those files from
git rmthe patchfiles
git log --oneline deps/V8
git diff-treestep below.
patches/v8/README.mdto see which patchfiles came from the previous version of V8 and therefore need to be removed.
(In node repo)
git diff-tree --patch HASH > ~/path_to_libchromiumcontent/patches/v8/xxx-patch_name.patch
xxxis an incremented three-digit number (to force patch order)
patch_nameshould loosely match the node commit messages, e.g.
030-cherry_pick_cc55747,patchif the Node commit message was "cherry-pick
(remainder of steps in libchromium repo)
Manually edit the
.patch file to match upstream V8's directory:
If a diff section has no instances of
deps/V8, remove it altogether.
Replace instances of
git statusto make sure there are no unstaged changes.
script/patch.py -r src/V8 -p patches/v8/xxx-patch_name.patch.patch
Create a new copy of the patch:
cd src/v8 && git diff > ../../test.patch && cd ../..
Confirm that checksums are the only difference between the two patches:
diff -u test.patch patches/v8/xxx-patch_name.patch
Replace the old patch with the new:
mv test.patch patches/v8/xxx-patch_name.patch
Add the patched code to the index without committing:
cd src/v8 && git add . && cd ../..
Add the patch file to the index:
git add a patches/v8/
(Optionally) commit each patch file to ensure you can back up if you mess up a step:
git commit patches/v8/
patches/v8/README.mdwith references to all new patches that have been added so that the next person will know which need to be removed.
Update Electron's submodule references:
$ cd electron/vendor/node electron/vendor/node$ git fetch electron/vendor/node$ git checkout electron-node-vA.B.C electron/vendor/node$ cd ../libchromiumcontent electron/vendor/libchromiumcontent$ git fetch electron/vendor/libchromiumcontent$ git checkout upgrade-to-chromium-X electron/vendor/libchromiumcontent$ cd ../.. electron$ git add vendor electron$ git commit -m "update submodule referefences for node and libc" electron$ git pso upgrade-to-chromium-62 electron$ script/bootstrap.py -d electron$ script/build.py -c -D
Node maintains its own fork of V8
We update code such that we only use one copy of V8 across all of electron
We don’t track upstream closely due to logistics:
libcc is large and time-consuming to update, so we typically choose the node version based on which of its releases has a version of V8 that’s closest to the version in libcc that we’re using.
Electron keeps all its patches in libcc because it’s simpler than maintaining different repos for patches for each upstream project.