Bug 37207

Created attachment 53422 [details] intial suggestion as conversation starter

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

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.

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

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?

(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?

(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...

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

(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.

(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?

(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.

(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.

(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.

Created attachment 54692 [details] proposed change QtWebkit 2.0 version will be 4.7.0.

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>

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

(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.