On Wed, Dec 12, 2012 at 3:03 PM, Attila Csipa <[email protected]> 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 _______________________________________________ Development mailing list [email protected] http://lists.qt-project.org/mailman/listinfo/development
