[Development] QtWebKit is coming back (part 2)

Fri May 5 09:04:13 CEST 2017

Hi,

There has also been some interest also for getting Qt WebEngine to be released much faster cycle than Qt – exactly due to the security update need. Even if we succeed in making substantially more frequent Qt patch releases than before, it may still be better if user would have the option to update some parts (like QWE) more frequently or out of sync. 

I think what we should consider, is to perhaps carve out Qt WebEngine from Qt as well. Not immediately, but for Qt 6 we should anyway consider our current setup of essential and add-on modules. For the html5 engine there is the matter of binary size in addition to release frequency. This is not to say that we would stop developing html5 engine – just that it might be beneficial to do in in different way than currently. 

For new updated Qt Webkit, perhaps we could have it as a separate item that works on top of Qt 5.9 for those to use it who prefer it over Qt WebEngine. After it has existed for a while as a separate item, it is also easier to know what would be the best way to get it into a Qt release – or is that even necessary. 

Yours,

	Tuukka

On 04/05/2017, 22.26, "Development on behalf of Konstantin Tokarev" <development-bounces+tuukka.turunen=qt.io at qt-project.org on behalf of annulen at yandex.ru> wrote:

    04.05.2017, 19:35, "Oswald Buddenhagen" <oswald.buddenhagen at qt.io>:
    > On Thu, May 04, 2017 at 04:51:45PM +0300, Konstantin Tokarev wrote:
    >>  03.05.2017, 17:27, "Sergio Martins" <sergio.martins at kdab.com>:
    >>  > On 2017-05-03 15:02, Konstantin Tokarev wrote:
    >>  >>  Remaining question is versioning. While it's fine to dub current
    >>  >>  release "5.9" (but not 5.0, because we will have another WebKit update
    >>  >>  in 5.10 time frame), using Qt versions in QtWebKit has downsides:
    >>  >>
    >>  >>  1. It is not clear if 5.N+1 ships with the same WebKit branch as 5.N,
    >>  >>  or is updated
    >>  >>  2. It makes people believe that QtWebKit 5.N should be used with Qt
    >>  >>  5.N only. QtWebKit supports wide range of Qt versions (starting from
    >>  >>  5.2 as of now), and can be used e.g. as security update in Linux
    >>  >>  distro that does not normally update Qt version during its life cycle.
    >>  >>
    >>  >>  Any comments?
    >>  >
    >>  > If Qt and QtWebKit will have different release schedules then that
    >>  > numbering would indeed confuse people.
    >>
    >>  What about choice of new versioning scheme?
    >>
    >>  I'm leaning towards "6.0.0" number, because it's larger than any 5.x and makes it
    >>  clear that versioning is different now. Bug fixes will increment patch version (6.0.x),
    >>  WebKit updates minor version (6.1.x etc), API/ABI breaking changes - major
    >>  verison (7.0 etc.)
    >>
    >>  Qt5 supermodule will be tracking latest available stable branch. When release branch
    >>  is created (e.g. 5.10.0), corresponding patch release branch is created in qtwebkit
    >>  repo (e.g., 6.1.1) and is frozen following the same schedule as Qt release branches.
    >>
    >>  However, I'm not sure about two things:
    >>  1) Is it possible to have custom branch names in qtwebkit repository, or there need to
    >>  be virtual 5.10 etc. branches to match other modules?
    >>  2) What about bug tracking in JIRA? I would like to keep existing issues as is, but assing
    >>  new release numbers to items fixed in new releases
    >
    > i'll say outright that you can't be part of the qt supermodule and yet
    > have independent releases. while that was the plan once upon a time, the
    > whole release infrastructure simply doesn't deliver, and even just
    > diverging branch names are a pita (proved by enginio). as a product, qt
    > is as monolithic as ever.

    Understood: no custom branch/tag names in official repo.

    >
    > your release cycle concerns seem to be centered around the webkit
    > backend, and you can deal with that by lowering the compatibility
    > guarantees of patch releases at this level, i.e. take the freedom to
    > upgrade webkit in a patch release. as long as you keep qt's api/abi
    > compat promises, you're fine. that means that you will not be able to
    > expose new webkit features until the next minor release if they require
    > new api.

    That's probably fine with me, except 2 moments that seem to require "out of band" releases:

    1. Something should be done with current release. As I said, it's not an option to postpone
    it to 5.10, however it also cannot be released as 5.9.1 because there are API additions
    which I don't want to revert (in particular because these APIs were already shipped by
    Linux distros that chose to provide TP4 and TP5). Also there is a change in QDataStream
    format of QWebHistory.

    2. Security updates. WebKitGTK team provides several patch releases for each stable branch,
    which contain only fixes for bugs and security issues, and towards the end of release life cycle
    they became primarily security updates. I think we should be able to release such updates ASAP,
    by making up some tag name and scheduling custom build against newest patch release of Qt.

    > _______________________________________________
    > Development mailing list
    > Development at qt-project.org
    > http://lists.qt-project.org/mailman/listinfo/development

    -- 
    Regards,
    Konstantin
    _______________________________________________
    Development mailing list
    Development at qt-project.org
    http://lists.qt-project.org/mailman/listinfo/development