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]>: > Hi Alan, > > > On 18 Sep 2015, at 20:13, Alan Alpert <[email protected]> wrote: > > > > On Fri, Sep 18, 2015 at 8:12 AM, Nurmi J-P <[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] > http://lists.qt-project.org/mailman/listinfo/development > -- Filippo Cucchetto
_______________________________________________ Development mailing list [email protected] http://lists.qt-project.org/mailman/listinfo/development
