[webkit-qt] QtWebkit2.1 version number

[Ademar Reis]

On Tue, Dec 21, 2010 at 12:21 PM, Ademar Reis <ademar.reis at openbossa.org> wrote:
> On Tue, Dec 21, 2010 at 11:57 AM, Simon Hausmann
> <simon.hausmann at nokia.com> wrote:
>> 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 :)
>
> How cute and beautiful! (NOT!) :-)
>
> But well, if that's not considered a problem by you Qt guys, then I
> guess we just have to add a workaround on symbian and keep the
> versions as they are. Please make sure that every library which gets
> decoupled from Qt (my understanding is that QtWebKit is the first)
> follows the same policy.
>

Hi there.

This topic is actually open for discussion on this Qt modularization ticket:
http://bugreports.qt.nokia.com/browse/QTBUG-15971

Please follow the ticket and add comments there if you're interested
in this topic.

Cheers,
  - Ademar

-- 
Ademar de Souza Reis Jr. <ademar.reis at openbossa.org>
OpenBossa - Instituto Nokia de Tecnologia