[webkit-qt] Conclusion (was RE: Proposal: Qt 4 removal from trunk, Qt 5 changes)

Simon Hausmann simon.hausmann at nokia.com
Wed Jun 13 01:02:37 PDT 2012


On Wednesday, June 06, 2012 02:10:06 PM ext Jocelyn Turcotte wrote:
> My quick opinion on it is that we could:
> - Switch the official bots to Qt5 as soon as possible to aid the Qt5 beta
> - Branch Qt4 at the same time as Qt5 (two different branches would be better
> I guess) - Remove the Qt4 code from trunk (that might be broken already
> since the bots won't be running) once we stabilized the Qt5 branch

I think in general that's the way to go, but

    1) We don't know yet what the Qt5 branching plans will be (a subject of 
discusion at the Qt CS)

    2) Before branching off WebKit for Qt 5 I want to be finished with all major 
things, which includes the Windows build as well as the QtWebKitWidgets 
renaming. Especially the latter is going to be a PITA to do if I have to keep 
the build working with Qt 4 at the same time, just to get rid of the work 
again after branching.

So I'd like a timeline like this:

    1) Remove Qt 4 code from trunk
    2) Branch off Qt 4 port from trunk, revert Qt 4 removal, keep merging 
WebKit trunk (this is the key, continue merging trunk!)
    3) Do the QtWebKitWidgets renaming and maybe Caio can also land his font 
layout test results?
    4) Remove the QtScript dependency in trunk and replace the WK1 part where 
we use the QScriptEngine::Ownership enum with an enum in QWebFrame (this is 
source incompatible but discussed a while ago with Lars and relatively minor)
    5) Branch off WebKit trunk for Qt 5.0.x, at that point also stop merging 
WebKit trunk into the qt 4 branch, to ensure that both have the same WebKit 
feature set.

Does that sound reasonable?


Simon

> On Wed, 6 Jun 2012 09:37:14 +0200
> 
> ext Allan Sandfeld Jensen <kde at carewolf.com> wrote:
> > On Wednesday 06 June 2012, simon.hausmann at nokia.com wrote:
> > > Hm, okay, maybe we can improve the timing :)
> > > 
> > > What would be the advantage of waiting until Qt 5.0 is released? What
> > > would
> > > be different at that point?
> > 
> > By branching of the same version as Qt 5.0 it will hopefully benifit from
> > the stabilization up to Qt 5.0, plus it means we can hopefully keep the
> > QtWebKit for Qt 4.x version close to the branch used for Qt 5.0, which
> > means we can possible merge similar patches, etc.
> > 
> > From an communication POV it is also simpler to explain that this fork
> > will
> > provide the features available in QtWebKit for Qt 5.0 to Qt 4.x (except
> > WebKit2 of course).
> > 
> > 
> > `Allan
> > _______________________________________________
> > webkit-qt mailing list
> > webkit-qt at lists.webkit.org
> > http://lists.webkit.org/mailman/listinfo.cgi/webkit-qt
> 
> _______________________________________________
> webkit-qt mailing list
> webkit-qt at lists.webkit.org
> http://lists.webkit.org/mailman/listinfo.cgi/webkit-qt


More information about the webkit-qt mailing list