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....@qt-project.org
<development-bounces+simon.hausmann=theqtcompany....@qt-project.org> on behalf
of Filippo Cucchetto <[email protected]>
Sent: Sunday, September 20, 2015 13:55
To: Nurmi J-P
Cc: [email protected]
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
<[email protected]<mailto:[email protected]>>:
Hi Alan,
> On 18 Sep 2015, at 20:13, Alan Alpert
> <[email protected]<mailto:[email protected]>> wrote:
>
> On Fri, Sep 18, 2015 at 8:12 AM, Nurmi J-P
> <[email protected]<mailto:[email protected]>> 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
[email protected]<mailto:[email protected]>
http://lists.qt-project.org/mailman/listinfo/development
--
Filippo Cucchetto
_______________________________________________
Development mailing list
[email protected]
http://lists.qt-project.org/mailman/listinfo/development
