Hi again! On Mon, 9 Nov 2020 at 15:51, Shawn Rutledge <[email protected]> wrote: > > > > > On 9 Nov 2020, at 19:27, Shawn Rutledge <[email protected]> wrote: > > > > > >> On 2 Nov 2020, at 17:15, Thiago Macieira <[email protected]> wrote: > >> ]qml is like Python: because of plugins, it's tied to the Qt version. > >> Therefore, it fails the requirement for supporting everything the old > >> version > >> supported. > > > > Well if you were using modules that are no longer supported, or you run > > into some little incompatibility; but we have been trying to avoid API > > breaks. QML files that begin with “import QtQuick 2.0” still work fine so > > far; also Controls, Layouts etc. So IMO it’s less onerous than the python > > upgrade. > > … but your point was not about QML file compatibility but about the mere fact > that we have a BC break, so users need two versions of the qml interpreter > installed at the same time, right? And I still rather like the idea of just > installing them in different > places, and having a symlink to point to the one you want to use. If distro > maintainers insist that /usr/bin/qml must be an executable and not a symlink, > then I guess it should be the Qt 6 version, to go along with the fact that > we’re pushing the open source > community pretty hard to upgrade as soon as it’s released.
If the qml binary is **only** used at build time then yes, it can be hidden. If it's used as a script interpreter then you need to provide both at the same time, because even in the fastest Qt 6 adoption times you will have to support both Qt 5 and 6 versions for at very least 6 years. Believe me, I did that with Qt 4 and 5 :-) -- Lisandro Damián Nicanor Pérez Meyer http://perezmeyer.com.ar/ http://perezmeyer.blogspot.com/ _______________________________________________ Development mailing list [email protected] https://lists.qt-project.org/listinfo/development
