Hi, > On 20 Sep 2015, at 15:35, Jocelyn Turcotte <[email protected]> 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? -- J-P Nurmi _______________________________________________ Development mailing list [email protected] http://lists.qt-project.org/mailman/listinfo/development
