[Development] QML import versions

[Alan Alpert]

On Sun, Sep 20, 2015 at 11:56 AM, Robin Burchell <robin+qt at viroteck.net> wrote:
> On Fri, Sep 18, 2015, at 08:15 PM, Nurmi J-P wrote:
>> > I have some opposition to the idea because it entirely prevents us from
>> > making changes if they are needed. An example of this came up just the
>> > other day on IRC: Window{} has a number of major (or at least quite
>> > irritating) flaws. A few of us were discussing whether/how it would be
>> > possible to fix them in a QtQuick.Window 3.0, without breaking backwards
>> > compatibility with older code, and without waiting for Qt 6.
>>
>> I think it’s a reasonable trade-off. Qt has lived with this restriction
>> for quite long. :)
>
> I think the reason that the imports system evolved in this direction was
> because it was considered to be too limiting, and in the case of QML,
> not necessary because of the capability to provide backwards
> compatibility. You can't easily use Qt 4 and Qt 5 in the same codebase,
> you could use QtQuick.Window 2 and QtQuick.Window 3 in the same
> codebase, theoretically.
>
>> If this is about the Item-based Window, would it make sense to give a
>> different name? Panel? Popup? There’s also something related in the works
>> in Qt Quick Controls 2.
>
> Without wanting to go too far off on a tangent here:
>
> I personally think that a concept that maps to a Window deserves to be
> called a Window. Definitely not Panel or Popup at least as both of those
> have different meanings in windowing, and neither of them match on
> desktop platforms (sure, on platforms *without* windows, it does).
>
>> >> How often do we release new major versions of QML modules? I don't see why QML
>> >> modules couldn't follow the same practices than the rest of Qt follows.
>> >
>> > At present, we don't, but I think that's more down to the low amount of
>> > activity happening outside the engine (at present) rather than the lack
>> > of a _need_ to in some areas. Adopting this policy would mean there is
>> > zero chance of these ever happening outside of major Qt releases, which
>> > ties things to a much longer timeframe than "whenever we feel like
>> > bumping the major version number".
>> >
>> > To me, that feels like a pretty big loss, even if I can see the appeal
>> > we get in having consistency.
>>
>> Yeah, it’s a big limitation, but I’d vote for consistency for the sake of
>> pleasant Qt Quick experience. It would also mean that we wouldn’t be able
>> to release Qt Quick Controls 2.0 as is. We could release some parts of it
>> under a different import, though.
>
>> The QML version mess has been bothering me for a long time, and as I
>> tried to illustrate in the initial email, it keeps getting worse every Qt
>> release… :(
>>
>> > It also means we're bumping version
>> > numbers for the sake of bumping version numbers in cases where there
>> > really aren't any (or at least many) changes, in the case of e.g.
>> > Particles, which is less of an issue, but still an issue.
>>
>> Is it any different to bumping the version of, say, QtXmlPatterns?
>
> No, but one doesn't do something like "#include
> <QtXmlPatterns/5.6/FooBar>" (unless one is using private API, in which
> case it's all your fault, you're a horrible person, and you deserve
> everything you get).
>
> In other words, those version numbers are a lot more transparent to the
> developer & end-user, unless they specifically rely on new
> features/bugfixes. This is both a good thing (meaning that we have more
> freedom to make changes), but a bad thing (due to potential
> inconsistencies in how it's approached, and e.g. the massive smattering
> of version numbers that we have now)
>
> In QML, the version numbers are directly exposed to the developer. This
> means that it would be a lot easier to, say, import QtQuick.Particles
> 5.7, and stop that application working on any prior version of Qt purely
> because we decided to bump the import version, when there are no changes
> in the module at all.
>
> Maybe another solution towards this problem would be removing minor
> versioning from our vocabulary altogether, and simply using a major
> version number for imports:
>
> import QtQuick 2
> import QtQuick.Window 2
>
> ... and so on.
>
> Functionality is always available (unversioned) in that import. Code
> written for older versions will Just Work on newer versions (as it does
> now). Code written for newer versions will Just Work on older versions,
> unless it relies on newer features (as it does now, just with a
> different error message: admittedly it might be a less descriptive one -
> you'd get told that the type/property didn't exist, as opposed to module
> version foobar is not available - but this is also the case with C++
> usage now!).
>
> Or am I missing some other value offered by minor version numbers?

Here is the scenario:

import QtQuick 2

Item {
    property bool scrollGestureEnabled: false
    MouseArea {
        onClicked: console.log(scrollGestureEnabled)
    }
}

In QtQuick 2.4 that would get the scrollGestureEnabled off of the
Item, in QtQuick 2.5 it resolves to the new MouseArea property. So
code like this will inexplicably break at run time when the system Qt
updates :( .

By using "import QtQuick 2.4" explicitly, that can't happen. That is
the value offered by minor version numbers. It is the mechanism by
which we achieve "Code written for older versions will Just Work on
newer versions".

The QML versioning is different to the C++ versioning because QML is
an interpreted langauge and C++ is not. C++ links to symbols at
compile time meaning that whatever you complied it against pretty much
works (so long as we maintain binary compatibility). QML versioning
aims to give that same behavior with an interpreted language, so that
whatever you developed it against still works out in production
environments with updates, but it needs language level features (the
versioning system) to do it.

--
Alan Alpert