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@qt-project.org https://lists.qt-project.org/listinfo/development