On 9/21/2015 6:51 PM, Alan Alpert wrote: > On Mon, Sep 21, 2015 at 3:36 AM, Hausmann Simon > <[email protected]> wrote: >> or Go, then we can see that the approach of automatically always importing >> the latest version is known to cause more headaches >> than do good. Very quickly the users want to be able to _pin_ to a certain >> version and be themselves in control when to "upgrade" >> to newer API.
Let me put it this way. If we trust ourselves enough not to have QT_REQUIRE_VERSION(arc, argv, "5.4.0") ...in every single .cpp file, why do we think QML absolutely must have it? In other words, why is #include <QtQml> so much safer than import QtQml ? Finally, no matter how you pin, you will be getting the new implementation - is there an example that Qt actually retained a different implementation for older imports, not counting QtQuick1 vs QtQuick2? >> I still don't know why people feel they need to do this. Touch the >> files that you want >> to use new features in, and if the others are importing a different >> minor version that's >> okay. Then the work is only marginally bigger than the actual new >> feature work in your >> application. A big point of the QML versioning system is that multiple >> imports of the >> same module can co-exist happily in the same engine. Because your import will, in practice, match your latest Qt version used for development, not the *API level* required. If you touch a property that doesn't exist, again, you will be bumping to the latest version, not the version that introduced the feature (as there is no simple way of figuring out what the "required" version would be). At some point you just stop fighting it and say "okay, latest it is" (or go back to whatever old Qt you wish to target). >> import QtQuick >> >> >> should resolve to exactly version 2.4. >> >> In other words: I think we should allow application developers to use just >> "import QtQuick" in their qml files - without a version. But all that >> should mean is that when the engine encounters a version-less import, it >> should look for the project configuration file to pick the version the >> developer would like to choose. > Since we don't have an existing central place for where to look, I > think this connection isn't obvious in the code (where it should be > easily readable). I like the concept though, maybe it could be "import > QtQuick from Project" or "import QtQuick from ../project.qmldir" to > give a direct link to the program configuration file. > This is fine - just please make this accessible/configurable from the .pro files in a reasonable way. It still doesn't solve the problem of optional features (ie in a worst case scenario, you still need to have as many qml files as there are Qt versions if you want to maintain backward compatibility as opposed to all liberties of dynamic properties as provided by MOC). Regards, Attila _______________________________________________ Development mailing list [email protected] http://lists.qt-project.org/mailman/listinfo/development
