[Development] QML import versions

[Jocelyn Turcotte]

> On 20 Sep 2015, at 19:34, Nurmi J-P <jpnurmi at theqtcompany.com> wrote:
> 
> Hi,
> 
>> On 20 Sep 2015, at 15:35, Jocelyn Turcotte <jturcotte at woboq.com> wrote:
>> 
>> - It would be nice to be able to increase a module’s major version without waiting for Qt6
> 
> I can see the desire to implement and release new major versions - we developers love rewriting things. :) But in the end it’s the poor Qt Quick user that pays the price in terms of confusion.
> 
> Co-existing major versions of QML modules can get nasty really quick. No matter how compatible or incompatible we declare them, indirect imports easily pull different major versions into the same engine. It may work for some QML module, or it may cause amusing meta-system level conflicts, for example.
> 
>> else we would have to replace “import QtQuick.Controls 2.0” by “import QtQuick.Controls2 1.0” or “import QtQuick.ControlsNg 1.0”
> 
> Or we could release the most important part of it as “templates” and leave the visual QML layer as an example.
> 
>> view.setMinimumQtVersion(5, 5); // Could default to the Qt version used to deploy the app
> 
> I like this idea. What happens when the requirement is not met, though? What about dynamically loaded components?

Not sure, maybe that ends up meaning in the end is that we want the user to be able to use the version of the distributed module package rather than the version of the API. But then it can’t be tied to Qt itself if the module is distributed on its own. It could then be specified per module like:

pragma require QtDeclarative 5.5
pragma require Qt3D 5.5
pragma require SomeExternalKDEModule 0.9

import QtQuick.Window
// or
import QtQuick.Window 2
// or
import QtQuick.Window 2.2

Or be put directly in the import like Filippo suggested. We could maybe have something like qmlRegisterRevision to bind individual API revisions to their packaging version.

It’s more API book-keeping though, not sure if it’s worth it. Keeping both ways of working together will probably end up making things more confusing than they already are, while switching the version model, even for Qt6, isn’t worth it if it means breaking source compatibility IMO.

So while it’s an idea fun considering, after thinking about it I’m not sure if it’s better than simply using the package version directly in the import like you suggested.

Cheers,
Jocelyn