[Development] QML import versions

[Attila Csipa]

WARNING: Flammable reply ahead.

On 9/21/2015 9:07 AM, Nurmi J-P wrote:
> That would a massive improvement, but it boils down to the same 
> problem. It can only be like that if Qt and QML version numbers match. 
> We cannot sprinkle qtquick versions to the base classes in qtbase.

As a third party developer working w both commercial and (L)GPL versions 
of Qt, for me QML versioning has been an enigma at best, and a hindrance 
at worst.

The original intent, I'm told, revolves around "compatibility", but in 
reality, it's closer to an API contract (so you're actually better off 
at thinking about it as dynamic linking to a .so file than anything 
else). This, however, in a QML context, makes little sense, for the 
following reasons

1. Theory: "use the lowest version you need". Practice: "use latest and 
greatest, otherwise you'll always be lost"
     - The documentation doesn't mention when an element/attribute was 
introduced (or if it does, it's the Qt version which does not relate to 
the import version)
     - The documentation will always want you to import as called in the 
latest version of Qt
     - Autocomplete helps a bit by listing all the available versions, 
but still, no idea as to which one of those is which Qt (or which ones 
you used previously)
- There is no version check/fallback mechanism for QML imports at either 
compile or runtime (no, having a separate QML files for each Qt version 
is not a solution), which makes availability-driven incremental feature 
enablement impossible. On the C++ side, you can at least if/ifdef for Qt 
versions.

2. Import versioning is crude, there is no * or +, you have to aim for 
exact versions

3. import statement versioning gets out of sync - after a while, it 
invariably degenerates into a mishmash of versions as the projects 
evolves through newer and newer versions of Qt

4. No way of verifying what Qt version you're actually compatible with 
(even if you keep around older versions of Qt, the dynamic nature of QML 
means you have to test extensively if something is actually working 
100%). Plus remember - you're importing *API* contracts, not 
implementation (if a bugfix in Qt 5.6 fixes something that inadvertently 
breaks your app, importing 5.5 will not "save" you).

4b. To make it worse, the is no way of checking of QML version 
compatibility at qmake time (you have to "know" what Qt version you need)

5. Suffers from versioning logic inconsistency compared to the C++ side. 
Bumping QML API versions in vain is a no-no, while the C++ side bumps 
regardless (modules don't claim they are 5.2 or 5.3 just because there 
were no changes introduced in the given module's API - they're all Qt 
5.latest)

The only use-case I can think of where the whole import versioning 
scheme makes some remote sense is:
     - Custom QML pugins (as those might have release cycles unrelated 
to Qt)
     - Platforms where you're sentenced to using a system-provided Qt 
(say, apps that want to go into the public repos of Linux distros)
     - FOSS projects where, for whatever reason, people might compile 
with outdated Qt builds

Whichever it is, my experience is - controlling QML compatibility 
reliably is a world of pain.

Long story short:
I use a patched Qt(creator) that a) doesn't check versions (implicity 
does "use latest"), and b) compiles QMLs in QRCs so it appends that 
"latest" version numbers available to the binaries. If I compile with Qt 
5.5, and people try to use it with <5.5 I'm on the mercy of the 
forward-compatibility gods anyways.

As a developer, if I could, I would introduce a syntax that would either 
abolish QML versioning altogether (or relegate it to the level of Qt 
Versioning). Ideally, I'd like to see

import QtQml
import org.custom.plugin 1.3

forcing me to specify anything else does not help - by the time that 
import QtQml statement is evaluated, I already compiled, linked and ran 
a certain version of Qt. If I didn't check up to that point either on 
the qmake or cpp level what I can do with that QtQml (and I need to be 
compatible with something that is not latest-greatest), I'm doing it 
wrong anyway.

Best regards,
Attila
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.qt-project.org/pipermail/development/attachments/20150921/eb86bd98/attachment.html>