[Development] QML import versions

[Alan Alpert]

I found part of the previous discussion, see my essay from 2012 which
explains the versioning system: http://alan.imagin-itis.net/?p=322

It even has an answer for "Why not just use Qt versions?" (but it's a
little out-of-date).

Additional answers to Attila's questions inline below.

On Mon, Sep 21, 2015 at 11:58 AM, Attila Csipa <qt at csipa.in.rs> wrote:
> 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
>
> ?

Here's a scenario corresponding to the one I gave Robin as to why QML
needs minor versions.

#include<QtQml>

class QQmlFlange {
};

flange = new QQmlFlange()

Now in the next minor version of Qt, say we add a QQmlFlange class to
QtQml. A application built against the current version of Qt, but
linking to system libraries, will continue to work fine. The name
resolution happened at the linker stage and so a new symbol in the
shared library doesn't affect the behavior of the compiled binary.
"flange" will still be an instance of the local QQmlFlange and you
won't hit the name conflict until you try to compile against the new
Qt version.

Contrast to the example I gave Robin, where the QML name resolution
happens at runtime, and you can see why #include<QtQml> is 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?

Yes, QtQuick.Window 2.0 is implemented using the QQuickWindow class,
in QtQuick.Window 2.1 we moved it to QQuickWindowImpl. Not an entirely
separate implementation, and the differences are deliberately minor
(because it's a minor version) but if we added a QtQuick.Window 3.0
any time soon we'd keep these two classes around.

If you aren't counting QtQuick 1 vs QtQuick 2 (and presumably aren't
counting Qt.labs.*), you're currently left with no major version bumps
within Qt Essentials modules and so no "older imports" exist at all.

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

Okay, so you bump to the latest version instead of the strict minimum
required whenever you touch a property that doesn't exist. You still
don't need to update files that aren't using any "new" features.

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

The optional features support is terrible, I would like to see an
improvement there. But it's a separate issue.

--
Alan Alpert