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

[André Pönitz]

On Thu, Nov 27, 2014 at 08:13:32AM +0000, Koehne Kai wrote:
> > [...]
> > 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.

Right. That's why behaviour changes should be kept to a minimum in general,
restricted to "obvious" bug fixes, performance improvements etc. Of course
this is a grey area, and people do not alway agree on what's reasonable
(see e.g. the thread about conversions via QVariant)

But they are easier to cope with in C++ code, at compile, link *and*
runtime. Postponing everything to runtime and hoping that the installed
version *somehow* mimics the original behaviour well enough for your
particular use case is a way to disaster.

If at all, this works only on strictly controlled platforms and strict
policies for applications, not on open systems.

> > #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 ... 

The proposal was not to use the C preprocessor exactly but something that
fits the purpose. 

> > 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 ...). 

Full files are usually not the granularity at which compatibility problems
appear.

And Loaders. How "declarative"...

Andre'