[Development] QML import versions

[Nurmi J-P]

Hi Alan,

> On 18 Sep 2015, at 20:13, Alan Alpert <416365416c at gmail.com> wrote:
> 
> On Fri, Sep 18, 2015 at 8:12 AM, Nurmi J-P <jpnurmi at theqtcompany.com> wrote:
>> Hi all,
>> 
>> I'd like to propose that all QML imports that are part of the Qt Essentials start following the respective Qt version number.
>> 
>> Let's take a look at the version history of some of the QtQml and QtQuick imports.
> 
> You missed a few key ones at the beginning:
> 
> ### Qt 4.7.0
> 
> - Qt 4.7
> 
> ### Qt 4.7.1
> 
> - QtQuick 1.0
> 
> ### Qt 4.7.4
> 
> - QtQuick 1.1


Heh, yeah, I was focusing on how the situation looks like to a user that installs Qt these days, but we can bring in the whole history to the discussion. To me, this doesn’t make the QML versioning look anyhow better, but more like a way to bend the rules. Greetings to the Nokia machinery that desperately needed new features but couldn’t afford waiting for the next minor version of Qt.


>> ### Qt 5.0
>> 
>> - QtQml 2.0
>> - QtQuick 2.0
>> - QtQuick.Particles 2.0
>> 
>> In the beginning, everything was cute, fluffy, and consistent.
> 
> QtQuick 1.1 was still around, just wholly incompatible with the
> previous modules (something we'd like to avoid in the future). That's
> why QtQuick.Particles started at 2.x, because series 1 was still
> active (and there is a QtQuick.Particles 1.0 implementation somewhere
> too).
> 
> Note also that around the Qt 5.0 release, and ever since, there were a
> lot of discussions about getting back to the Qt version number. Sadly
> I can't seem to find the emails right now. I seem to recall that the
> Qt Mobility modules went that direction in Qt 4.7 times (I'll need
> someone else to tell the story of how that went).


What happens in the past, stays in the past. :) Incompatibility between Qt Quick 1 and 2 is not that different from incompatibility between Qt 4 and 5. It’s too late to speculate on that, but perhaps it was a mistake to pull Qt Quick 1 into Qt 5...


>> Everyone can judge by themselves how coherent this looks like. :) A while ago the Qt Creator team needed help (QTCREATORBUG-14575) figuring out the available import versions in different Qt releases. I had lost track a long ago, so I actually had to read git log to find out. Now imagine a poor new user that installs Qt. It might not always be the latest available version, but specified by the project. How are they supposed to navigate in this jungle of QML versions?
> 
> They use the version with the features they need, instead of trying to
> use a "latest" which they may not need? For users and Qt Creator
> purposes we've discussed keeping a mapping or a wiki page, but that
> never seemed to get off the ground. If we could keep the .qmltypes
> files up to date, then that could be a viable mechanism too.


Think about the documentation, for instance.

If a property documentation says “introduced in Qt 5.9", the user doesn’t know what version to import in QML. If it says “introduced in QtQuick.Layouts 1.5”, the user doesn’t know what Qt version is required.

A wiki page with a huge version mapping table doesn’t seem like an attractive solution. 


>> What makes the situation even more cumbersome, to ourselves who develop these modules, is that there's no convention on how new properties are revisioned. Some classes are using a running revision number that gets incremented whenever new members are added, whereas others match it with the minor version of the module or Qt.
> 
> The former is the "official" convention (not that I know where it's
> documented ;) ). As it's an internal development detail I'm not
> surprised it's slipped through code review.


Here's a pseudo code review request that adds a new property:

    + Q_PROPERTY(int foo READ foo WRITE foo NOTIFY fooChanged REVISION 3)

    + qmlRegisterType<QQuickSomething,3>(uri, 1, 7, “Something”);

How do I know that any of the above numbers are correct? If they matched the Qt version, I could tell without looking up in the code or git history.


>> Is this something that would be possible to implement already in Qt 5, or is this Qt 6 material? Does someone strongly oppose the idea? 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. Ironically, we've been working on this thing called Qt Quick Controls 2.0... :P
> 
> So what's not possible is the conceptual conflict between arbitrary
> and semantic version numbers.

Qt, as a whole, uses semantic versioning. I wish that was that only version number that users had to remember.

--
J-P Nurmi