On 9 February 2018 at 15:54, Lars Knoll <lars.kn...@qt.io> wrote:
>> On 9 Feb 2018, at 07:52, Kevin Kofler <kevin.kof...@chello.at> wrote:
>> André Pönitz wrote:
>>> I think you need to start differentiating between Qt-without-Webengine
>>> and QtWebengine.
>>> And maybe "we" should do that, too.
>> I would be entirely in favor of separate (more frequent and/or more aligned
>> with Chromium security fixes) QtWebEngine releases. I am already updating
>> QtWebEngine in Fedora on a separate schedule from the core Qt updates (with
>> the intent of delivering security updates faster), so it would not be a
>> problem for me if the releases were entirely separate. And it would surely
>> get security fixes delivered in a more timely manner.
> We’ve been discussing this in the past, and most people agreed that releasing
> QtWebEngine on an independent schedule would be a good thing. But there’s
> still a couple of things that need sorting out before that can happen, both
> in the CI and how we create/package our product and SDK as well as in
> QtWebengine which for example still uses private API of some other parts of
Is updating the Chromium backend alone a source- and binary-compatible
act? I'm wondering if it's feasible (and desirable) to introduce
"sub-patch" releases, where the only change is the updated Chromium
backend -- not even bugfixes in Qt-controlled code. For example, if
Chromium is updated between Qt 5.10.0 and Qt 5.10.1, then:
1. Branch off the v5.10.0 tag (call it the "5.10.0-x" branch, for
Chromium updates only)
2. Update Chromium in 5.10.0-x and release "Qt WebEngine 5.10.0-1"
3. Merge 5.10.0-x into 5.10
The idea is to provide security updates in a timely manner, without:
* Worrying about private API breakages
* Requiring a full-blown Qt release
* Making Qt WebEngine's version numbering go out of sync with the rest of Qt
This approach would be most beneficial for a non-LTS branch, least
beneficial for an LTS branch in "Very Strict" mode. I thought this
might be an easy option since Qt WebEngine is already listed as a
separate component in the Qt installer (please correct me if I'm
underestimating something in the process).
Development mailing list