[Development] Qt 6 co-installability with Qt 5
thiago.macieira at intel.com
Wed Feb 17 23:39:49 CET 2021
On Wednesday, 17 February 2021 00:32:13 PST Joerg Bornemann wrote:
> Yes, and that's all good, and with
> https://codereview.qt-project.org/c/qt/qtbase/+/334054 we will have an
> offical recommendation.
> I will also add a documentation page in the vicinity of
Make that "mac building" too, because it shall apply to Homebrew. Windows has
no concept of global paths, so it doesn't matter there.
I also think the step should be automatic from the CMake build, instead of an
optional extra. That will lead to confusion because people will forget and
then send questions into forums and mailing lists.
> The only thing we're still arguing about is how to call the tools in the
I think we should follow the majority, both in quantity and in volume.
All but one of the binary distributions will rename. That's all the Linux
distributions, FreeBSD ports tree, Homebrew on Mac, and possibly Conan on
Therefore, we do request that it be made obvious that it is called "qmake6"
and "qtdiag6" almost everywhere.
The official build from qt.io, which is much less important these days because
it can't be anonymously downloaded, can be the odd one out if it wants to. I
suggest that you do apply the new name there too, but that's your choice. Just
don't make your minority choice rule the user experience for the majority.
> To mention that the distro-provided qmake might be called qmake6 can
> (and should) also be done. But to change qmake to qmake6 everywhere in
> the docs is as consistent as not doing anything - as long as we don't
> rename the tools.
I agree with the arguments.
Therefore, I come to the conclusion the tools should be renamed.
> Renaming just the three tools you mentioned would be inconsistent.
> Renaming all tools is too late.
No, it isn't. We agreed that 6.1 would be an acceptable target for this
massive change because we didn't want to risk 6.0, therefore it is acceptable.
No one is currently using 6.0 because it's incomplete for many applications
and because it is a dot-zero release.
Also note that the longer those modules go unmaintained, the bigger the chance
people will simply begin porting away from Qt entirely. I've already been
asked that question inside Intel: projects that were on the last LTS (5.12)
are trying to figure out their futures.
Thiago Macieira - thiago.macieira (AT) intel.com
Software Architect - Intel DPG Cloud Engineering
More information about the Development