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

[Volker Hilsheimer]

Sounds like y’all have a wonderful new business opportunity ahead of yourselves: charge your new-leaf-app-on-old-OS customers handsomely for the extra effort. After all, you do have to keep your Windows 7 test rigs around (and secured); perhaps even pay some extra retainers to those developers on your team that know about those Windows 7 quirks. That can’t be cheap in terms of net and esp opportunity cost!

Share some of the remaining profit with my employer to get access to the commercial-only 5.15 LTS releases.

Cheers,
Volker


________________________________
From: Development <development-bounces at qt-project.org> on behalf of Kevin Kofler <kevin.kofler at chello.at>
Sent: Tuesday, June 16, 2020 1:36:54 AM
To: development at qt-project.org <development at qt-project.org>
Subject: Re: [Development] Windows 7 support will be dropped in Qt 6

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)

_______________________________________________
Development mailing list
Development at qt-project.org
https://lists.qt-project.org/listinfo/development
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.qt-project.org/pipermail/development/attachments/20200616/6dc6da91/attachment.html>