Bug 37207 - [Qt] QtWebKit 2.0 library version needs to be maintained in WebCore.pro
Summary: [Qt] QtWebKit 2.0 library version needs to be maintained in WebCore.pro
Status: CLOSED FIXED
Alias: None
Product: WebKit
Classification: Unclassified
Component: Tools / Tests (show other bugs)
Version: 528+ (Nightly build)
Hardware: All All
: P2 Normal
Assignee: QtWebKit Unassigned
URL:
Keywords: Qt
Depends on:
Blocks: 35784
  Show dependency treegraph
 
Reported: 2010-04-07 06:53 PDT by Simon Hausmann
Modified: 2010-05-02 14:59 PDT (History)
4 users (show)

See Also:


Attachments
intial suggestion as conversation starter (992 bytes, patch)
2010-04-15 04:47 PDT, Janne Koskinen
no flags Details | Formatted Diff | Diff
how it looks on Qt side (1.23 KB, patch)
2010-04-15 04:48 PDT, Janne Koskinen
no flags Details | Formatted Diff | Diff
proposed change (2.09 KB, patch)
2010-04-29 06:18 PDT, Janne Koskinen
hausmann: review+
Details | Formatted Diff | Diff

Note You need to log in before you can comment on or make changes to this bug.
Description Simon Hausmann 2010-04-07 06:53:52 PDT
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.
Comment 1 Janne Koskinen 2010-04-15 04:47:39 PDT
Created attachment 53422 [details]
intial suggestion as conversation starter
Comment 2 Janne Koskinen 2010-04-15 04:48:25 PDT
Created attachment 53423 [details]
how it looks on Qt side
Comment 3 Janne Koskinen 2010-04-15 04:55:22 PDT
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.
Comment 4 Simon Hausmann 2010-04-16 16:03:03 PDT
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
Comment 5 Simon Hausmann 2010-04-16 16:06:06 PDT
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?
Comment 6 Jocelyn Turcotte 2010-04-19 01:09:25 PDT
(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?
Comment 7 Janne Koskinen 2010-04-19 23:57:23 PDT
(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...
Comment 8 Kenneth Rohde Christiansen 2010-04-26 05:37:20 PDT
Any update on this? I'm personally OK with so.4.20
Comment 9 Jocelyn Turcotte 2010-04-26 05:46:15 PDT
(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.
Comment 10 Janne Koskinen 2010-04-26 23:14:53 PDT
(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?
Comment 11 Janne Koskinen 2010-04-27 01:14:45 PDT
(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.
Comment 12 Simon Hausmann 2010-04-28 04:10:20 PDT
(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.
Comment 13 Jocelyn Turcotte 2010-04-28 06:57:28 PDT
(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.
Comment 14 Janne Koskinen 2010-04-29 06:18:27 PDT
Created attachment 54692 [details]
proposed change

QtWebkit 2.0 version will be 4.7.0.
Comment 15 Simon Hausmann 2010-05-02 14:51:16 PDT
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>
Comment 16 Simon Hausmann 2010-05-02 14:58:44 PDT
Revision r58661 cherry-picked into qtwebkit-2.0 with commit 09985156d31032da87aab00472943af2860baf04
Comment 17 Simon Hausmann 2010-05-02 14:59:40 PDT
(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.