[Interest] Keeping QML module versions up to date in a project

[Koehne Kai]

> -----Original Message-----
> From: interest-bounces+kai.koehne=theqtcompany.com at qt-project.org
> [...]
> Still - the only guarantee you get with a specific import version is that of the
> API, but not the behavior. Thus, it's perfectly possible that someone swaps
> the libs and your app *IS* affected. See for example the "QML instantiation
> performance thread". You likely won't blow up, but far from "can't be
> negatively impacted" by having the lib updated behind your back.
> 
> To add insult to injury, it's actually pretty hard to find out what was
> introduced when, so your imports will reflect "which version of Qt I
> developed my app with" rather than "what Qt features does my app
> require".

Well, this isn't a problem specific to QML versioning, is it? A bug fix in Qt
might also break your existing C++ application if it relied on the old, 'broken'
behavior.

> Thus, the way versioning is done, combined with a lack of conditionals is
> making it really hard to maintain a QML file/app when you're not the one
> bundling the Qt libs. I still fail to grasp why this is such a no-no. If it's okay to
> have a
> 
> #if QT_VERSION >= QT_VERSION_CHECK(5,3,0)
> 
> ...why can't we have something functionally equal for QML? 

To be fair, the C++ macro expander is regarded by quite a few people as
a necessary evil, not a feature new languages should aim for ... 

> As it is now,
> whenever I decide to add support for a new feature, I make my QML
> incompatible with older Qt versions (which is understandable) with no way of
> defining a fallback or alternative (which is not OK) regardless how trivial the
> new feature is.

One benefit of QML is that you can do switching between different QML files
trivially at runtime (for example by using a QFileSelector , or by using a Loader 
element ...). 

Regards

Kai