[Development] QtWebKit is coming back (part 2)

[Oswald Buddenhagen]

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.

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.