[Development] QtWebKit is coming back (part 2)

[Konstantin Tokarev]

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