[Development] Convenience Imports in QML

[Alan Alpert]

On Wed, Dec 12, 2012 at 3:03 PM, Attila Csipa <qt at csipa.in.rs> wrote:
> On 12/12/12 23:01, Alan Alpert wrote:
>>
>> Major version means high-level incompatibilty, so if you import QtQml 2.0
>> now don't expect it to just work with QtQml 3.0. Minor version means
>> features, which actually means some low-level incompatibilty because it's a
>> different language to C++. So QtQml 2.1 is mostly the same as QtQml 2.0,
>> just some new features, but you still should check that the new features
>> don't lead to resolution conflicts before you redeploy. So QML modules might
>> have to jump the major/minor version separately to Qt, and vice-versa (no
>> new QML symbols? Don't update your module version number just because it's
>> Qt 5.1!). Imagine
>
>
> Yes, I agree on the principle, but the implementation gets in the way on
> many fronts.
>
> As said, there is no semantics or relation in the version numbers. Thus even
> if a new 2.1 *is* a known, verified, and perfectly compatible superset of
> 2.0, the import will get rejected (as far as the import mechanism is
> concerned, these versions could have been called "apple" and "orange").

What do you mean, rejected? The existence of 2.1 doesn't invalidate
the existence of 2.0. As they're within the same major version, 2.1
and 2.0 elements can even live happily in the same tree.

>
> This, in fact, means: No backward *or* forward compatibility. While we all
> live on the bleeding edge, this is cool. But, imagine you have Qt5 on X
> million devices, and Y thousand of apps that do import QtQml 2.0. All is
> well. Somebody decides to change a property, bump to QtQml 2.1 or 3.0 and on
> the next firmware/Qt update you essentially preemptively break *ALL*
> applications because *SOME* might be incompatible. The scenario that an
> application is compatible with a Qt update is almost impossible (even on
> Harmattan which stuck to QtQuick 1.1 from beginning to end people still
> managed to occasionally burn themselves along the way of PR1.1/1.2/1.3,
> N9/N950 differences, etc). Same is true for the reverse - even if you *know*
> your QML works with previous version(s) of QtQml, unless you package a
> separate QML for each version and do some fallbacks, it won't work on it's
> own.

Wrong. If you bump the latest QtQml to 2.1 in Qt 5.2 we still provide
QtQml 2.0, so we break *NO* applications because *SOME* might be
incompatible. For the developers they need to update to use the latest
features but guess what? That's something they'd need to do anyways to
use the latest features.This is an even stronger compatibility than Qt
has, because if you try to run a Qt 4 application against Qt 5, it
breaks. If you try to run a QtQuick 1.0 application (which somehow
magically isn't a Qt 4 application as well) against Qt 5, it still
works. Same with QtQuick 1.1. Until you actually port your application
to use the awesome new features, it just works as before - which is
the best that a deployed application can do.

> But there are other, smaller inconveniences, too - the "million branches"
> scenario. How would Ubuntu, Debian or the others work? Now you take package,
> run a build script and everything is dandy. Not so fast! With this
> dependency system, you actually need to go through all the sources and
> manually update everything so that you match the host system - having some
> distro-specific flavor in a build directory is not enough any more. There is
> no pkg-config, dynamic versioning even if you DID verify it to work. Every
> version of your app is SUPER-TIGHTLY glued to the versions provided by a
> particular Qt5 release. That was one of the beauties of Qt - if it worked on
> 4.5, chances were it was either working out of the box or needed just a
> recompile even if used with 4.8.4. With the current versioning scheme, I'll
> need a separate branch for *EVERY* single minor Qt5 release or enter QML
> file cloning hell. I expect git skills improvement :)

Wrong again. This is actually the same as Qt. If you wanted to use a
new feature from 4.8.4 then you'd need a branch or an #ifdef because
it wouldn't work against 4.5. If you didn't use any new features, it
just needed a recompile at most (and probably shouldn't have even
needed that). Again, if you don't actually use any of the new features
in QtQuick 1.1, you just leave your Qt 4.7.1 "import QtQuick 1.0" apps
as "import QtQuick 1.0" and they'll still work fine with Qt 4.8.4.
Shouldn't even need a recompile. If you want to use features from the
new QtQuick 1.1 you'll have to update the import statements and use
the new minor version as a minimum but again this is exactly the same
as Qt.

>
> I understand that this can be appealing because of "compatibility
> guarantees", the flip side, right? Not so fast. Even simple things like
> fixes can get tricky. Imagine there is a bug in 2.0. It gets fixed in the
> next Qt release, but then there is no guarantee of how something will work
> and you can't detect the difference from the QML side. There will be builds
> with a version 2.0 that work and there will be builds with version 2.0 that
> don't - so where IS that rock-solid guarantee we are getting for the extra
> maintenance burden, then?

There's never a perfect guarantee, but we try our best. Which is why
qtquick1 is a separate module with a copy of the old engine still
using qtscript. We could have dropped half the QtDeclarative module
and made all QtQuick 1 in Qt5 run on QML 2 but we didn't, to avoid
massive 'bug compatibility' issues. That goes a long way, and in my
opinion counts as 'rock solid' (at least as solid as talc).

--
Alan Alpert