[Development] Convenience Imports in QML

[Attila Csipa]

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").

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.

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 :)

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?

Best regards,
Attila