[Development] QtWebKit is coming back (part 2)
Lars Knoll
lars.knoll at qt.io
Mon May 8 14:22:07 CEST 2017
On 8 May 2017, at 13:37, Jani Heikkinen <jani.heikkinen at qt.io<mailto:jani.heikkinen at qt.io>> wrote:
Couple of comments below
br,
Jani
-----Original Message-----
From: Development [mailto:development-bounces+jani.heikkinen=qt.io<http://qt.io/>@qt-
project.org<http://project.org/>] On Behalf Of Konstantin Tokarev
Sent: maanantaina 8. toukokuuta 2017 12.56
To: Tuukka Turunen <tuukka.turunen at qt.io<mailto:tuukka.turunen at qt.io>>; Oswald Buddenhagen
<Oswald.Buddenhagen at qt.io<mailto:Oswald.Buddenhagen at qt.io>>; development at qt-project.org<mailto:development at qt-project.org>
Subject: Re: [Development] QtWebKit is coming back (part 2)
05.05.2017, 14:15, "Konstantin Tokarev" <annulen at yandex.ru<mailto:annulen at yandex.ru>>:
05.05.2017, 10:04, "Tuukka Turunen" <tuukka.turunen at qt.io<mailto:tuukka.turunen at qt.io>>:
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.
BTW, let me bring an attention to the elephant in the room.
Yes, my fork of QtWebKit existed for a while as a separate item. But
it was never and "official" successor, and even me myself was warning
people that it is not an official replacement as some features are not yet
restored.
However, now there is no valid reason to keep using QtWebKit contained
in 5.9 and dev branches anymore. Feature parity is achieved to the
level of drop-in replacement that can be applied system-wide. Still many
people see 5.9 branch as a source of truth.
We need to convey a message to wide audience that old QtWebKit should
no longer be used, and that there is a new release that should be used
instead. Not only with Qt 5.9.0, but also with older Qt releases, down to Qt
5.2.x if people still use it (e.g., Ubuntu 14.04).
This is why question about version numbers and related stuff is
important. If this is not done, it doesn't matter at all whatever tag
names will be picked and what schedules will be followed.
Since Qt 5.6 QtWebKit is in "removed" state and according to [1] it even does
not exist, I think it should be to make exceptions in branch and release
management policies for
5.9 and 5.9.0 branches, solely to resolve situation described above.
Actually 'old ' webkit is in our builds but not part of official releases, see e.g https://testresults.qt.io/coin/integration/qt/qt5/tasks/1494068162
That is because we have agreed to keep it working and deliver src packages for the releases as well. Not part of official release but in addition.
As I said in my other mail, we could easily drop those unsupported packages. Maybe quickly check whether the 5.8 packages compile against Qt 5.9. If they do, there’s no need at all to release packages that are the same, but remove the option of using the new version number for the updated engine.
I propose the following plan:
1. Merge wip/next into 5.9.0, 5.9, and dev. 5.9.0 contents will correspond to
"alpha" release, that has feature parity, but is not yet guaranteed to be
polished enough.
To be honest, I don't want to do this now. From release schedule point of view it is just too late, we cannot risk our Qt 5.9.0 release schedule because of this. At this point 5.10 should be enough. For me it is ok if you want to add TP/Alpha etc in http://download.qt.io/community_releases/5.9/ but being part of official ci builds in '5.9.x' it is too risky.
Yes, we can’t couple this to our Qt 5.9 release. It clearly comes too late for that.
In addition, I am not convinced it’s a too good idea, we were never really happy with that tight coupling for our web engine(s) in the past. So I’d propose we rather first try to figure out if we can keep those decoupled from a releasing perspective. This might create some challenges in how we handle things from a packaging/CI side, but working through those items might be helpful in the longer term, and something we could then start considering for web engine as well.
Cheers,
Lars
2. Host sources and binaries of QtWebKit corresponding to 5.9.0-alpha
release at http://download.qt.io/community_releases/5.9/
This should be OK as well
3. For dev branch, follow all necessary procedures to change status of
QtWebKit and make it work for Qt 5.10 without any schedule exceptions.
[1] http://doc.qt.io/qt-5/qtmodules.html
Yours,
Tuukka
On 04/05/2017, 22.26, "Development on behalf of Konstantin Tokarev"
<development-bounces+tuukka.turunen=qt.io at qt-project.org<mailto:development-bounces+tuukka.turunen=qt.io at qt-project.org> on behalf of
annulen at yandex.ru<mailto:annulen at yandex.ru>> wrote:
04.05.2017, 19:35, "Oswald Buddenhagen"
<oswald.buddenhagen at qt.io<mailto: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<mailto: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<mailto:Development at qt-project.org>
> http://lists.qt-project.org/mailman/listinfo/development
--
Regards,
Konstantin
_______________________________________________
Development mailing list
Development at qt-project.org<mailto:Development at qt-project.org>
http://lists.qt-project.org/mailman/listinfo/development
--
Regards,
Konstantin
_______________________________________________
Development mailing list
Development at qt-project.org<mailto:Development at qt-project.org>
http://lists.qt-project.org/mailman/listinfo/development
--
Regards,
Konstantin
_______________________________________________
Development mailing list
Development at qt-project.org<mailto:Development at qt-project.org>
http://lists.qt-project.org/mailman/listinfo/development
_______________________________________________
Development mailing list
Development at qt-project.org<mailto:Development at qt-project.org>
http://lists.qt-project.org/mailman/listinfo/development
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.qt-project.org/pipermail/development/attachments/20170508/ef3e6a08/attachment.html>
More information about the Development
mailing list