QtWebEngine/UpdatingOlderBranches

Guide to updating WebEngine on LTS branches

Updating in general

In general, we follow the guidelines for cherry-picking patches from dev to stable and stable-lts releases. We have a bit of an exception to the rest in Qt since our public branches will stay open even though the release has transitioned to LTS. For non-LTS minor-versions, we ask for the branch to remain open, then we try to keep them open for as long as we are using the branch in one of the LTS releases. Once a newer minor version is considered stable enough (usually after the x.y.1 or x.y.2 release), we start using it in LTS release that preceded it.

Types of updates

Regular fixes

These are usually fixes in the Qt WebEngine code that also apply to the LTS branch. The rules for picking them are basically the same as for all picks from dev / newer branches.

Security patches and backports from Chromium

Security patches are critical fixes that are applied to all active qtwebengine-chromium branches that they are relevant for, and then pulled into the qtwebengine branch through submodule updates. The qtwebengine-chromium branches are always public and always open. The same qtwebengine-chromium branch can also be used by multiple qtwebengine branches.

The main source for security patches are the Chromium release notes that list the CVEs that have been fixed in a release as well as provide links to the list of bugs that were internally found and classified as relevant to security. Unfortunately, for most of these bugs, membership on the security-notify list for Chromium is necessary. Some bugs that are still not entirely fixed or otherwise still under an embargo will not be accessible even to members of the security-notify list. In this case, finding the fixes can be a bit challenging and require grepping for the bug number in either the source code repositories or the chromium code review tools.

Backports from Chromium are patches from newer versions that are needed to fix the functionality of the older branch, fix the build for etc.

Methods for backporting

In short, there are three methods for backporting:

• cherry-pick: the patch can be applied directly or with minimal changes using git am
• manual cherry-pick: although the patch cannot be applied during git am, the code can still be manually applied unchanged by copying it into the code base by hand
• manual backport: the patch is applicable and needed in general, but requires adjustments because the code bases have diverged too much

We often indicate which method was used to apply a patch as a convenience to the reviewers and other users.

Updating from the public branch to the LTS branch

While the public branch is still open, fixes are simply picked or backported from dev, and then the whole public branch is merged into it's tqtc/lts counterpart:

Updating the LTS branch to the next patch level versions

Once a newer minor version is considered stable enough (usually after the 6.x.1 / 6.x.2 release), we usually update the previous LTS branch to use it. This is currently done by merging the branch into the LTS-branch and fixing code that relies on API that was only released in newer versions of Qt, either by reverting the changes or by providing an alternative implementation.

While the newer version is still receiving releases, we simply do regular merges from the public branch of the newer minor version. This should ideally follow a same pattern as the outlined above, i.e.:

Problems with the current approach

Outdated dependencies in COIN

Unfortunately, this sometimes causes problems, because while the public branch of Qt WebEngine might stay open, the other branches, including the top level one, will close, which makes it difficult and sometimes impossible to update the dependencies in coin to the new Web Engine branch. In this case, we currently pick the fixes from dev or pull in the fixes in the qtwebengine-chromium submodule to the tqtc/lts branch. While all changes are still either public in the qtwebengine-chromium submodule or pulled in from a public branch, the cherry-picks and submodule updates are not publicly accessible until the opensource release of the lts branch.

Last minute fixes

Sometimes, we need to updates directly on the release branch because there has been a last minute fix or a new Chromium release containing security fixes has just come out. This creates the need to pick the fixes either directly from the lts-patch-release branch to the lts- branch or to the public branch first and from there to the lts-branch, which needs a bit of care and practice to not create some conflicts later on.