[Development] QML and Qt Quick versioning of our modules

[Olivier Goffart]

Am Donnerstag, 7. Dezember 2017, 14:53:06 CET schrieb Frederik Gladhorn:
> Hi all,
> 
> I've lately been discussing with a few people in The Qt Company about our
> versioning.
> Historically it was a good idea to not couple Qt Quick too tightly to
> general Qt releases. There were quite some constraints and added
> flexibility was nice. Qt Quick has matured a lot though, so I think it's
> time to consider making everyone's lives easier by cleaning up our version
> chaos.
> See also J-P's previous mail here: http://lists.qt-project.org/pipermail/
> development/2015-September/023200.html
> 
> Examples are the version section in here:
> https://doc.qt.io/qt-5/qtquickcontrols2-index.html
> And a general confusion around which version does what.
> Since we so far don't keep copies of old functions around (as far as I'm
> aware at least), I don't think there's a huge value in the versioning
> system in the first place.
> It only gives one important guarantee: if you added a property/type/name and
> import a defined version, you don't suddenly get conflicts because we
> introduced the same name.
> 
> Some modules started to copy the Qt version, e.g. Multimedia, that's pretty
> easy to remember and a good start in my opinion.
> 
> I have several ideas and I'm unsure how hard they would be to implement, so
> I'll list things from easy to hard.
> 
> 1) sync minor versions to Qt release version:
> For Qt 5.11, we would provide QtQuick.Controls 2.11
> This way, the challenge for the user is only to find out if it's version 1,
> 2 or 5.
> 
> 2) Make the minor version import optional and we pick the lastest. This
> should be optional to prevent the name clashes described above and shifts
> the risk to the user.
> In practice I'd expect this to be pretty safe.
> import QtQuick.Controls 2 would then give the latest version available.
> 
> 3) Make even the major version optional and we'd pick up the latest version.
> import QtQuick.Controls would give version 2.11 with Qt 5.11.
> 
> I don't see us releasing most of the QML/Qt Quick modules independent of the
> rest of Qt any time soon, so I hope this will make things easier for
> everyone. I'm sure there are even better ideas out there, this is just my
> version and current thinking, I hope for constructive suggestions :)
> 
> In the end I want this to be easier for Qt users and also to lessen our
> maintenance burden and the need to look up versions, explain the scheme and
> reduce the confusion.
> 
> Luckily we now have qmlRegisterModule(QT_VERSION_MAJOR, QT_VERSION_MINOR) to
> help registering the current versions already.


Thanks for bringing the discussion up.

In my opinion, this import is not so useful and I would vote for making it 
optional

I also think that Q_REVISION is defective by design and we should not try t 
support this.
I know that it is supposed to make sure that new property/function names don't 
clash with application name. But do we have any data that this indeed was 
usefull? Is there any project that upgraded Qt and had his qml still working 
because there would be a conflict.
The QML engine should throw a warning when this happen (that the lookup would 
be different with a newer version), and we could see in the real world if this 
happen.

-- 
Olivier