[Development] Windows 7 support will be dropped in Qt 6

Kevin Kofler kevin.kofler at chello.at
Tue Jun 16 01:36:54 CEST 2020


Edward Welbourne wrote:
> How many of those Win 7 users are routinely upgrading the software on
> their systems ?  Given that they're not updating the O/S, it seems
> reasonable to presume that they are, at least, somewhat conservative
> about upgrades; they don't want the shiny new features the folk you
> dismiss as "cool kids" are upgrading for, so why would they care if the
> Qt apps they're using are upgraded to Qt 6 ?  Surely such conservative
> users are likely to *prefer* to have such updates as they do take in
> contain only security fixes - i.e. the sorts of change that happen on an
> LTS version of Qt, rather than the radical change that comes with a new
> major version.

I cannot really know what goes in the mind of Windows users (as I cannot 
fathom why one would want to use that operating system to begin with), but 
at least here on GNU/Linux, it is a common request by users to want their 
core system to never change, but the latest&greatest applications on top of 
it. That, apparently contradictory, request is often hard to cater for, but 
it always keeps coming up (leading to ideas such as Fedora/RHEL Modularity, 
which come with their own can of worms, but that is not the topic here).

So, if Windows users are anything like GNU/Linux users, they will definitely 
want the latest leaf applications on their old Windows 7, which implies also 
the latest Qt if those applications happen to use Qt. Unless, of course, the 
developers of the application never upgrade to Qt 6, but surely that cannot 
be your targeted outcome.

Another possible outcome that I can imagine is somebody backporting the LGPL 
Qt 6 to Windows 7, which would not only be an enormous waste of developer 
effort (to basically readd all the compatibility code that you removed), but 
would also lead to a version of Qt circulating that you cannot quality-
control (chances are that such a community port would have more bugs than an 
official port) nor sell commercial licenses for (chances are that the port 
would never get submitted under your CLA, since it is unlikely that a 
patchset reverting a deliberate upstream change would ever get merged).

> For reference, at home I'm one of those conservative users - albeit on
> Linux - using Debian/stable and often sliding into Debian/old-stable
> rather than update, just because there's a newer stable available.  I
> like the stability and don't care so much about the shiny new things; so
> don't try accusing me of looking down on those who stick with the tried
> and trusted things they have; and don't try telling me that software
> developers should make sure their newest versions work on those stable
> systems, because I - like many such conservative users - don't want
> shiny new versions, I only want security fixes to stable versions,
> sacrificing shiny new features in favour of reliability.

I can tell you from experience that, while truly conservative users like you 
definitely exist (it's not just you), there is also plenty of user demand 
for shiny new applications on a conservative base system.

> That's adaptation by the app developers in their "new release" versions;
> we understand perfectly well that app maintainers (in so far as *they*
> care to continue supporting legacy versions of any O/S) also *want* to
> have a stable version, whose security and stability they know well from
> experience; which means sticking with LTS versions of the libraries they
> use.  Just as we have our stable branches and our shiny new version, app
> maintainers who care about supporting legacy platforms used by
> conservative users have their stable versions, that they maintain atop
> stable versions of their prerequisites.

That only works if you actually make your LTS versions available to the 
large community of Qt developers, most of whom use the LGPL version of Qt 
and cannot use commercial licenses for various reasons.

If the plan to provide LTS versions only to commercial customers is 
implemented for 5.15 as planned, LTS will be completely useless to the vast 
majority of Qt developers.

> If we *never* allow ourselves breaking changes, we'd still have a nice
> stable product that worked great on an O/S or two from the last century.
> Qt would thus be irrelevant.

Nonsense. We would have a nice stable product that just works on old and new 
operating systems alike. New operating systems are either supported out of 
the box thanks to backwards compatibility, or support can be added without 
any breaking changes.

Supporting a new operating system version does not require dropping support 
for older versions, and most definitely does not require the other (entirely 
unrelated) breaking changes (deprecations etc.) that are being implemented 
in Qt 6.

> Just had a quick look at that issue [QTBUG-74687]; and I note that it
> *didn't* ask your opinion, it set out to evaluate how practical it would
> be to drop Win 7.

Huh? How do you "evaluate how practical it would be to drop Win 7" WITHOUT 
listening to those who would actually be affected by it?

Your definition of "practical" seems to differ very much from mine.

        Kevin Kofler
(who will probably not be meaningfully affected, but takes offense at the 
way this decision is being made)



More information about the Development mailing list