[Development] Qt 6 co-installability with Qt 5

Lisandro Damián Nicanor Pérez Meyer perezmeyer at gmail.com
Mon Nov 9 19:56:28 CET 2020

Hi again!

On Mon, 9 Nov 2020 at 15:51, Shawn Rutledge <Shawn.Rutledge at qt.io> wrote:
> > On 9 Nov 2020, at 19:27, Shawn Rutledge <Shawn.Rutledge at qt.io> wrote:
> >
> >
> >> On 2 Nov 2020, at 17:15, Thiago Macieira <thiago.macieira at intel.com> 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

More information about the Development mailing list