[Development] QML import versions

[Filippo Cucchetto]

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>:

> 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
>
> _______________________________________________
> Development mailing list
> 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/20150920/9bd50838/attachment.html>