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"
<[email protected] on behalf of
[email protected]> wrote:
04.05.2017, 19:35, "Oswald Buddenhagen" <[email protected]>:
> On Thu, May 04, 2017 at 04:51:45PM +0300, Konstantin Tokarev wrote:
>> 03.05.2017, 17:27, "Sergio Martins" <[email protected]>:
>> > 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
> [email protected]
> http://lists.qt-project.org/mailman/listinfo/development
--
Regards,
Konstantin
_______________________________________________
Development mailing list
[email protected]
http://lists.qt-project.org/mailman/listinfo/development
_______________________________________________
Development mailing list
[email protected]
http://lists.qt-project.org/mailman/listinfo/development
