[Development] Online installer no longer lets users choose between Qt 5.3.0 and Qt 5.3.1

Ziller Eike Eike.Ziller at digia.com
Mon Jul 7 10:09:54 CEST 2014

On Jul 6, 2014, at 3:52 AM, Sze Howe Koh <szehowe.koh at gmail.com> wrote:

> On 4 July 2014 00:14, Thiago Macieira <thiago.macieira at intel.com> wrote:
>> On Thursday 03 July 2014 10:35:30 Koehne Kai wrote:
>>> Right, the files are still there. But to allow parallel installation (which
>>> is probably what you want if you e.g. are after regression testing) we'd
>>> need to repackage the old Qt 5.3.0 binaries , giving it a new installation
>>> path, changing Qt Creator kit / Qt version id's , names ...
>>> It's certainly possible, but I'm not sure whether it's really worth it,
>>> given that we still have offline installers.
> I can understand the benefits of the new approach. As the new releases
> come, the number of options in the installer would keep increasing so
> the new approach keeps that in check.
> Unfortunately there are downsides too:
> 1) Developers who face regressions (not just testers) are now in an
> awkward position, and need to install an extra copy of Qt Creator (see
> below)
> 2) In Qt Creator, the Qt version and kit are still listed as "Qt
> 5.3.0", even though it has been upgraded to Qt 5.3.1. Since it is an
> auto-detected entry, the user cannot change the name.

"Since it is an auto-detected entry, the user cannot change the name.” is actually wrong (you _can_ change the name), and that is actually the reason why the bug "Qt version and kit are still listed as “Qt 5.3.0”” exists ;)

Br, Eike

>> Is it possible to use the offline installer to install 5.3.0 into the existing
>> installation and not install a new Qt Creator?
> No. When running an installer (online or offline), Qt Creator is a
> compulsory component (although Qt itself is non-compulsory). I
> remember someone saying that Qt Creator is made compulsory because of
> interdependencies between the Maintenance Tool and Qt Creator.
> What are these dependencies? I'm willing to have a go at reducing this
> coupling, if I know where to look. I believe one of them is for the
> installer to register "auto-detected" kits. Instead of having the
> installer perform this registration, would it make sense for it to
> simply add a "search path" to a global Qt Creator config file, and let
> Qt Creator search for and register new copies of Qt at startup?
> Regards,
> Sze-Howe
> _______________________________________________
> Development mailing list
> Development at qt-project.org
> http://lists.qt-project.org/mailman/listinfo/development

Eike Ziller, Senior Software Engineer - Digia, Qt
Digia Germany GmbH, Rudower Chaussee 13, D-12489 Berlin
Geschäftsführer: Mika Pälsi, Juha Varelius, Tuula Haataja
Sitz der Gesellschaft: Berlin, Registergericht: Amtsgericht Charlottenburg, HRB 144331 B

More information about the Development mailing list