[Development] QML import versions

[Attila Csipa]

On 9/21/2015 6:51 PM, Alan Alpert wrote:
> On Mon, Sep 21, 2015 at 3:36 AM, Hausmann Simon
> <Simon.Hausmann at theqtcompany.com> 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