[Development] QML import versions

Mon Sep 21 12:36:10 CEST 2015

Hi,

I agree that something "new" needs to be put on the table in order to solve this. And "this" expands unfortunately

to a few issues at the same time.

I think that it would be a mistake of "import QtQuick" - without any version tag - would always import the latest available

version on the system. If we look into other development communities with package based environments such as Python (pip)

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.

I think that we should learn from this and this is why I think generally applying a version to the QML APIs is a good thing. I believe that what

we are missing is the convenience of making the conscious step of changing the of QtQuick 2.4 to 2.5 - it is incredibly tedious at this

point as it requires touching every single file.

Therefore I think that we should introduce the notion of configuration files that apply to an entire project. For QML modules that configuration

file is the qmldir file, although I'd prefer something different. For applications - the primary target audience in this thread - we are lacking a

central place where we could say that

     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.

This way one developer can try to bump the version in their copy of the application source code, try the app and see if there are any property

conflicts that needs resolving. Then he can commit that version bump, possibly together with files to .qml files that resolve conflicts.

Simon

________________________________
From: development-bounces+simon.hausmann=theqtcompany.com at qt-project.org <development-bounces+simon.hausmann=theqtcompany.com at qt-project.org> on behalf of Filippo Cucchetto <filippocucchetto at gmail.com>
Sent: Sunday, September 20, 2015 13:55
To: Nurmi J-P
Cc: development at qt-project.org
Subject: Re: [Development] QML import versions

I'm no troll, but i don't see any way to solve this without putting something new to the table

1) What about extending the a little bit the QML language itself.
Something like
import QtQuick as in 5.5
import QtQuick.Controls as in 5.5

so a way to specify to import a module at version when a specific Qt version was released.
Obviusly this doesn't disable the option for specifying a particular version.
So this should be fine
import QtQuick as in 5.5
import QtQuick.Controls 1.4

2) Another option is automatically use the latest version of a module if the version number
is not specified. So:
import QtQuick // Automatically imported with the latest version installed
import QtQuick.Controls // Automatically imported with the latest version installed

2015-09-20 13:43 GMT+02:00 Nurmi J-P <jpnurmi at theqtcompany.com<mailto:jpnurmi at theqtcompany.com>>:
Hi Alan,

> On 18 Sep 2015, at 20:13, Alan Alpert <416365416c at gmail.com<mailto:416365416c at gmail.com>> wrote:
>
> On Fri, Sep 18, 2015 at 8:12 AM, Nurmi J-P <jpnurmi at theqtcompany.com<mailto: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

_______________________________________________
Development mailing list
Development at qt-project.org<mailto:Development at qt-project.org>
http://lists.qt-project.org/mailman/listinfo/development

--
Filippo Cucchetto
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.qt-project.org/pipermail/development/attachments/20150921/f320ed7d/attachment.html>