Bug 37207 – [Qt] QtWebKit 2.0 library version needs to be maintained in WebCore.pro

• Component: Tools / Tests
• Status: CLOSED FIXED

[Simon Hausmann]

Currently WebCore.pro picks up the library version from Qt:

CONFIG(QTDIR_build) {
    include($$QT_SOURCE_TREE/src/qbase.pri)
    # Qt will set the version for us when building in Qt's tree
} else {
    VERSION = $${QT_MAJOR_VERSION}.$${QT_MINOR_VERSION}.$${QT_PATCH_VERSION}
    DESTDIR = $$OUTPUT_DIR/lib
    !static: DEFINES += QT_MAKEDLL
}

Instead we should set the version ourselves, i.e. we should start with 4.7.0 in the trunk and in the release branch.

[Janne Koskinen]

Created attachment 53422 [details]
intial suggestion as conversation starter

[Janne Koskinen]

Created attachment 53423 [details]
how it looks on Qt side

[Janne Koskinen]

Ok some commenting. Symbian needs to know the version of webkit when creating sis packages to make correct dependencies to DLL/installed webkit version.

Patch proposes to add a new file containing the version information under WebKit/qt tree where this is then included into webcore.pro.

When user makes a application using qtwebkit from Qt tree he will get the version that is currently coming with Qt. if user decides to install new webkit release he'd get the version from that tree. Downside is that he needs to set WEBKITDIR to this to work.

Another problem that is not visible from this patch (yet) is that we already have shipped Symbian QtWebkit with version 4.6.2 and upcoming 4.7.1 so we need to start QtWebkit 2.0 version from higher than those to maintain proper dependency to versions. My suggestion is that we start QtWebkit numbering from 20 i.e. every subsequent release of QtWebkit would have it's major version number multiplied by 10. Minor and Patch numbers would not be touched.

As you can see in the Qt side there is a fallback version. this fallback number would be used on times when QtWebkit version 2.0 would be installed on top of 4.6 but user would have not set WEBKIT dir. My suggestion for the fallback number is 4.6 or to print warning.

[Simon Hausmann]

To retain binary compatibility we have to keep on using the major version 4 for the qtwebkit 2.0 release and later.

In addition the minor version of the DLL with qtwebkit 2.0 has to be greater than 6.

Therefore 4.7 is a natural choice over 2.0

[Simon Hausmann]

In other words, Janne, when installing qtwebkit 2.0 over an existing Qt installation on Symbian, it is important that the pkg_depends_webkit from symbian/qt.prf includes the correct and _updated_ version number.

I think your approach of installing an optionally included .pri file is a good idea. Jocelyn, what do you think?

[Jocelyn Turcotte]

(In reply to comment #5)
> I think your approach of installing an optionally included .pri file is a good
> idea. Jocelyn, what do you think?

I'm for that as well


(In reply to comment #4)
> To retain binary compatibility we have to keep on using the major version 4 for
> the qtwebkit 2.0 release and later.
> 
> In addition the minor version of the DLL with qtwebkit 2.0 has to be greater
> than 6.
> 
> Therefore 4.7 is a natural choice over 2.0

If we ever create official releases between Qt SDK releases, numbering it 4.7 now will be confusing later.

What about starting from 4.20.0 then?

[Janne Koskinen]

(In reply to comment #6)
> (In reply to comment #5)
> > I think your approach of installing an optionally included .pri file is a good
> > idea. Jocelyn, what do you think?
> 
> I'm for that as well

Excellent.

> (In reply to comment #4)
> > Therefore 4.7 is a natural choice over 2.0
> 
> If we ever create official releases between Qt SDK releases, numbering it 4.7
> now will be confusing later.
> 
> What about starting from 4.20.0 then?

This was my reasoning for setting it to 20.0.0 from start. If next release is 4.7 then what will be the next one...

[Kenneth Rohde Christiansen]

Any update on this? I'm personally OK with so.4.20

[Jocelyn Turcotte]

(In reply to comment #8)
> Any update on this? I'm personally OK with so.4.20

Thought about it and 4.20 would cause problems when we get to 2.11. This would limit us to have max 10 minor releases per major.

Using 4.200.0 would probably give us enough of them.

[Janne Koskinen]

(In reply to comment #9)
> (In reply to comment #8)
> > Any update on this? I'm personally OK with so.4.20
> 
> Thought about it and 4.20 would cause problems when we get to 2.11. This would
> limit us to have max 10 minor releases per major.
> 
> Using 4.200.0 would probably give us enough of them.

And what about with Qt 5.0 release ? QtWebkit would still continue with 4.x series?

[Janne Koskinen]

(In reply to comment #10)
> > Using 4.200.0 would probably give us enough of them.

Here is an issue. Symbian binaries won't have separate minor and build number so when checking for dll eclipsing we compress  minor and build number into 2 bytes leaving 1 byte for each number i.e. minor and build number cannot be larger than 255.

[Simon Hausmann]

(In reply to comment #11)
> (In reply to comment #10)
> > > Using 4.200.0 would probably give us enough of them.
> 
> Here is an issue. Symbian binaries won't have separate minor and build number
> so when checking for dll eclipsing we compress  minor and build number into 2
> bytes leaving 1 byte for each number i.e. minor and build number cannot be
> larger than 255.

Good point.

What's wrong with just 4.7 then? :) If we can't find anything better, then let's continue with what we've done in the past.

[Jocelyn Turcotte]

(In reply to comment #12)
> What's wrong with just 4.7 then? :) If we can't find anything better, then
> let's continue with what we've done in the past.

We talked about it a bit here and I also think it would be alright to keep it to 4.7 for this release.

- The release and API version is QtWebKit 2.0 (and it's shipped with Qt 4.7, we can also say that it's Qt 4.7's QtWebKit version)
- The binary version is 4.7 (even if compiled with Qt 4.6)

Since we decided to ship QtWebKit 2.0 with Qt 4.7, the only difference with before is that we support to build it using Qt 4.6.

We probably won't get more than one QtWebKit release between Qt releases until a while so until then we will be able to keep the QtWebKit binary version same as Qt's one. Once we get a clearer view on how other Qt external modules want to handle their versions, we'll be able to go in the same direction.

[Janne Koskinen]

Created attachment 54692 [details]
proposed change

QtWebkit 2.0 version will be 4.7.0.

[Simon Hausmann]

Landed in the trunk with 4.8.0, as that's what QtWebKit 2.1's library version is going to be

Committed r58661: <http://trac.webkit.org/changeset/58661>

[Simon Hausmann]

Revision r58661 cherry-picked into qtwebkit-2.0 with commit 09985156d31032da87aab00472943af2860baf04

[Simon Hausmann]

(In reply to comment #16)
> Revision r58661 cherry-picked into qtwebkit-2.0 with commit
> 09985156d31032da87aab00472943af2860baf04

I should note that this cherry-pick has the library version set to 4.7.0 instead of 4.8.0 for the trunk.