[Development] Convenience Imports in QML

[Alan Alpert]

On Sun, Dec 16, 2012 at 4:02 AM, Attila Csipa <qt at csipa.in.rs> wrote:
> I don't necessarily care how different a shiny new API implementation is and
> if the fact that my application runs on it is purely coincidental based on
> how I use those APIs, but not having a way to say "YES, I know you bumped an
> API version, YES, I know there are potential incompatibilities, and YES, I
> tested it, and YES, it still works" is super-frustrating.

There's no way to say that because you don't need to say anything in
that case. If we bump the minor version and it still works (because
you aren't needing any of the new features) then it will still work
without you even having to alter your QML code to bump the version you
import. Would the following change help, if import Module x.y chose
the highest minor version available? So you import QtQuick 1.9, and it
will fall back to QtQuick 1.1 or 1.0, depending on which is available
on the system. This sort of functionality is what I think you're
asking for. Turns out that system is inferior to the current one,
because it has more developer effort for worse effects. You'd either
bump the minor version all the time, for the same effect as the
current system, or you'd use a large number to 'automatically' update
and risk breaking (because obviously you haven't tested against
QtQuick 1.9 yet). If you aren't using the new API then the lower minor
import continues to work, and if you are using the new API then the
lower minor import cannot work.

Note that the way the versioning system is implemented it is easy (and
strongly encouraged) to provide all minor versions of the module in
the package for that major version. So anywhere that supports QtQuick
1.1 should also support previous minor versions, like QtQuick 1.0.
That isn't strictly enforced by the engine, but should be enforced by
convention and the engine deliberately makes that case easy. As for
major versions, those are expected to be wildly different and
developers need to make a choice of major version explicitly, so not
being able to run the same code between QtQuick 1.x and QtQuick 2.x is
expected. It's like how you have to compile against Qt4 or Qt5, you
can't run the same binary against both (but because QML is an
interpreted language, the choice has to be made at runtime based on
the import statements). Eventually people will stop shipping Qt 4 and
then you'll need to provide your own if you want to keep running a Qt4
app - same with QtQuick 1. If the problem is that QtQuick 2 (or Qt 5
for that matter) looks so close that you thinks you *should* be able
to run the same code with the previous version, then you should be
disputing the choice to increment the major version instead of the
minor version.

--
Alan Alpert