On Tue, Dec 21, 2010 at 5:37 AM, Koskinen Janne <[email protected]> wrote: > Hi all, this is my last attempt on this even if the bug was closed etc.
Hi Janne. Do you have a reference bug on bugzilla? > > 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. This is definitely wrong. QtWebKit-2.1, as generated from the sources, should be qtwebkit-2.1.0. It could be versioned as qt-4.8.X only if imported to and built from qt sources. I've found the version 4.8.0 in WebKit/qt/qt_webkit_version.pri... Actually, the patch changing it is yours, back then in May :-) I guess the version was set as a placeholder but nobody remembered of it existence later on. > > 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. > > 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. > > This is simplification of the issue, add Symbian file eclipising, add version > number size restrictions and you start to feel why this is baaad. > > My original suggestion was to have QtWebkit 2.1.0 sis version to be > 20.1.0(0). Issue won't manifest until it is too late to do anything about it. > I'm not very familiar with symbian, but we have a similar problem with the lib soname on linux: the soname is currently libQtWebKit.so.4 and the file is libQtWebKit.so.4.8.0... So we don't have much choice... we could: 1. Change the project version everywhere to something like 20.x; 2. Keep the version as 2.x but internally use 20.x (not so internally, users will be exposed to it) Option (1) is the technically correct choice, but option (2) is far less painful right now. My suggestion is to adopt option (2) by now and later move to (1) - the migration will not break anything. Please let me know if there's a bug reference for that, otherwise I'll open one myself. Thanks for bringing this up. - Ademar -- Ademar de Souza Reis Jr. <[email protected]> OpenBossa - Instituto Nokia de Tecnologia _______________________________________________ webkit-qt mailing list [email protected] http://lists.webkit.org/mailman/listinfo.cgi/webkit-qt
