-
-
Notifications
You must be signed in to change notification settings - Fork 59
How to update WebKit (and JavaScript Core)
- Choose a stable version to update to
- Recreate the release branch in Git from the SVN repository Next time we should try using git-svn as per these instructions Disclaimer: fetching from SVN could take hours and occupy gigabytes so we need to carefully specify the refspec
- Tag the new branch with
git tag <tag-name>; git push origin <tag-name>
- Merge the tag in the
ios-official
branch. All conflicts must be resolved in favour of the new tag with theours
merge strategy:
git fetch
git checkout <tag-name>
git merge -s ours origin/ios-official
git push origin HEAD:ios-official
git checkout ios-official; git pull; git merge <tag-name>
- Merge the
ios-official
branch inios
with:
git checkout ios
git pull
git merge origin/ios-official
- Manually resolve all conflicts
- Build, test and fix any errors or bugs which might have been introduced
- Update scripts if needed - taking changes from webkit and applying them in ns-setup
- Choose a stable released version from webkit/releases/Apple
- Open the log of one of the directories, e.g. iOS 11.3/JavaScriptCore
- Find out which tag was released and use it later when checking it out from SVN (e.g. Safari-605.1.33.0.2)
Untested*: We can use these instructions to clone the branch directly from SVN. Should attempt this approach on the next update!
Since all git forks of the official WebKit repository lack the releases, tags and branches of the SVN repository we need to manually recreate the chosen version's state by applying the appropriate patches that have been added to the original repository. This process hasn't been automated and must be done manually by following these steps:
- Checkout the release tag in a new directory with
svn checkout 'https://svn.webkit.org/repository/webkit/tags/<tag-name>' WebKit-SVN
OR reuse your previousWebKit-SVN
directory withsvn sw https://svn.webkit.org/repository/webkit/tags/<tag-name>
- In
src/webkit
submodule checkout theios-official
branch OR the nearest trunk commit if a major new version will be taken. See Find the commit in master where to base the new release branch in git for more instructions.
cd <path-to-ios-runtime>/src/webkit;
git checkout <ios-official|<trunk-sha>>
- Delete the whole src/webkit submodule's working directory:
find <path-to-ios-runtime>/src/webkit -depth 1 -maxdepth 1 ! -name .git -exec rm -rf {} \;
- Copy all files to the WebKit submodule
find WebKit-SVN/ -depth 1 -maxdepth 1 ! -name .svn -exec cp -r {} <path-to-ios-runtime>/src/webkit/ \;
- Review and commit changes in
<path-to-ios-runtime>/src/webkit
stating how they have been obtained in the commit message. E.g.
Update WebKit from iOS 12.0 release
https://trac.webkit.org/log/webkit/releases/Apple/iOS%2012.0/JavaScriptCore
The whole source tree is copied from the corresponding tag https://svn.webkit.org/repository/webkit/tags/Safari-606.1.36.0.3
Whenever we update to a major new version of WebKit its better to base the new release branch (e.g. 12.x) on the first commit from master where the released SVN tag has diverged from trunk. This way the recreated release branch in git should have the smallest possible size, as it will only contain the differences that have been cherry picked in the corresponding SVN branch (but squashed in a single update commit). To find out which is this trunk commit do the following (shell commands are meant to be executed in the src/webkit
directory):
- Open the log of the chosen tag e.g. webkit/tags/Safari-605.2.3
- Find the text
copied from trunk
and take the message of the first commit after it. E.g.Standard controls sometimes say video is in pip when it isnt.
in the above example. - Locate it in the git repository's master branch and take it's SHA1 sum. E.g.
git log | grep -C 6 "<commit-message-first-line>"
- Create a new branch on top of this commit with
git checkout <SHA1>; git checkout -b <release-branch-name>
. Branch name should follow theios-<major-version>.x
convention.