Short summary for the TL;DR crowd: I don't necessarily care how different a shiny new API implementation is and if the fact that my application runs on it is purely coincidental based on how I use those APIs, but not having a way to say "YES, I know you bumped an API version, YES, I know there are potential incompatibilities, and YES, I tested it, and YES, it still works" is super-frustrating.
On 13-Dec-12 20:10, Alan Alpert wrote: > On Wed, Dec 12, 2012 at 3:03 PM, Attila Csipa <q...@csipa.in.rs> wrote: > >> 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. The point is there is no implied compatibility or relationship guarantee. Doesn't invalidate but doesn't guarantee anything either, and, if done wrong (like the Maps API in Mobility 1.2), can be even detrimental. > 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. No, you're looking at it from the wrong angle. As a developer, I have no way of knowing up front what you will be bumping and what that implies for MY application. QtQuick, an exception as it is, still demonstrates this well. Imagine my app using Rectangles only. I tested it with (Qt4.7, )QtQuick 1.0, 1.1 and 2.0 import statements and *verified* it works with all. All is well. But if I use the common approach to use the lowest that works, that opens the following potential problems - what if the particular Qt5 build I'm running on misses qtquick1 (to conserve space, incompatibility with cascades, you name it). Bork. What if Qt5 itself drops qtquick1 from the list of supported modules? Bork on the next version. Even though there is a *known* and *verified* import statement. This is the difference in terms of academic discussions and the trench-engineering realities - I don't necessarily care how different a shiny new API implementation is and if the fact that my application runs on it is purely coincidental based on how I use those APIs, but not having a way to say "YES, I know you bumped an API version, YES, I know there are incompatibilities, and YES, I tested it, and YES, it still works" is super-frustrating. The insult to injury is that the documentation is not too helpful wrt versioning. For example QtQuick 1.1 introduced a number of new properties for the Text element over QtQuick 1.0. Good luck finding out which properties you can use in a backwards compatible fashion from http://qt-project.org/doc/qt-5.0/qtquick/qml-qtquick2-text.html (which again pushes you to play it safe and always import the latest even if you don't necessarily need it). > > 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 It IS worse because there is *no* #ifdef in QML (unless you count the unreasonably cumbersome Component {} style loading), not even for the imports, much less the components themselves. > 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. As said, QtQuick is a good exception where this is *almost* true. It's an exception because it's the only module where the old version is still included, technically every other module has bumped versions in a lot less gentle way (Mobility stuff, Webkit, etc). And it's "almost true" because there was this "import Qt 4.7" glitch* in Qt 4.7.0. Again, I agree on the principle, but historically there was always a "good enough reason" (business, experience, maturity, deadline, you-name-it) why the clear QML versioning rules were implemented in a Matrix style some-rules-can-be-broken-some-can-be-bent way which made me a lot less enthusiastic about the general concept as implemented in Qt. The bottom line is the QML versioning acts as a straightjacket (for a reason, no dispute there), the pain comes from not providing any mechanisms to compensate for the reduced mobility. *an interesting "been there, done that" flashback that I got when the current "import Qt 5.0" proposal was made, we already had a "import Qt 4.7" for the almost same purpose which was later renamed into QtQuick (which technically *was* the "essentials" of the 4.7 days). Best regards, Attila _______________________________________________ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development