[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
http://perezmeyer.com.ar/
http://perezmeyer.blogspot.com/
More information about the Development
mailing list