> -----Original Message----- > From: interest-bounces+kai.koehne=theqtcompany....@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 _______________________________________________ Interest mailing list Interest@qt-project.org http://lists.qt-project.org/mailman/listinfo/interest