[webkit-qt] QtWebkit2.1 version number

[Simon Hausmann]

On Tuesday, December 21, 2010 03:45:28 pm ext Ademar Reis wrote:
> On Tue, Dec 21, 2010 at 11:35 AM, Simon Hausmann
> 
> <simon.hausmann at nokia.com> wrote:
> > On Tuesday, December 21, 2010 09:37:26 am ext Koskinen Janne wrote:
> >> Hi all, this is my last attempt on this even if the bug was closed etc.
> >> 
> >> QtWebkit.sis on QtWebkit2.1 branch is currently versioned as 4.8.0.
> >> If we keep this version when Qt 4.8 is out or new version of QtWebkit is
> >> released it will need to be incremented. This means that Qt 4.8 would
> >> have QtWebkit version 4.9 or that Qt 4.8 would have to ship with
> >> QtWebkit2.1.
> >> 
> >> Problem is that user will see this number if manually installing.
> >> Installer prompts "xxx needs QtWebkit 4.8.0(0), are you sure you want
> >> to install?" and will be pretty bad as there is no such version
> >> anywhere.
> > 
> > IMHO this is not a technical problem but an issue with the UI of the
> > Symbian installer, that in the first place shouldn't present the users
> > with questions about version numbers users shouldn't have to know about
> > in the first place.
> > 
> > I mean seriously, based on the provided information ("app needs foo
> > 4.8.0"), how can the user actually make an informed decision? ("are you
> > sure?")
> > 
> > So IMHO we shouldn't change version numbers just to work around UI issues
> > in Symbian.
> > 
> >> Worse problem is that smart installer will use these numbers to
> >> determine which version of QtWebkit is required to run application x.
> >> We cannot change the sis file numbers to 2.1.0 as we have already
> >> deployed Qt and there are applications that depend on QtWebkit version
> >> 4.6.3 or 4.7.0 and as such those version would have to be installed to
> >> be able to run them as they both are higher version than 2.x.x.
> > 
> > Right, so if we don't change anything right now, stick to 4.8, 4.9, etc.
> > , we'll be fine, no?
> > 
> >> This is simplification of the issue, add Symbian file eclipising, add
> >> version number size restrictions and you start to feel why this is
> >> baaad.
> > 
> > I admit I don't see why 4.8 and 4.9, etc. are bad. What other issues are
> > there?
> 
> Isn't it inconsistent to have the version set as 4.8.0, for example,
> if this is not the version included in Qt-4.8.0?
> 
> Also, if a developer wants to identify which webkit he's using, he'll
> look at the soname of the library. If libQtWebKit-4.8.0 is actually
> qtwebkit-2.1 and libQtWebKit-4.9.0 is qtwebkit-2.2 but the latest
> version of Qt is, say, 4.7.2, he'll be *really* confuse. It'll be even
> worse in a few years after Qt-4.8 and Qt-4.9 are released.
> 
> At least on linux, I would consider it messy to have the soname
> (technical version) not in sync with the release/documented version.
> It would be bad to have a "release numbers translation table", even
> worse to have versions resembling the original Qt versions.

It's quite common that the soname is different from the documented project 
version. KDE for example has been doing it for years with its libraries :)

$ ls -ld /usr/lib/libkdecore.so.5.5.0 
-rw-r--r-- 1 root root 2927384 2010-10-04 13:40 /usr/lib/libkdecore.so.5.5.0


I'm running KDE 5! :)

The package version however is correct:

ii  libkdecore5                                         4:4.5.1-0ubuntu7                                
the KDE Platform Core Library

(minus the epoch, but that's a different issue :)

Simon