Re: [Development] Windows 7 support will be dropped in Qt 6
Kevin Kofler (16 June 2020 12:08) >>> What "shiny new features"? All that a real-world application such as >>> KWrite really needs from the operating system has been there at >>> least since the 1990s, possibly since the 1970s. Edward Welbourne wrote: >> and I guess it's been in Qt for several releases now, so why would >> someone with those needs care about upgrading to Qt 6 ? Kevin Kofler (16 June 2020 19:25) > Because all KDE applications will have to get ported to Qt 6 soon. So, just to remind you, we were talking about ancient versions stretching back to the start of the century, when there was no C++11 compiler available for anyone to use to compile any recent version of Qt, much less KDE. So those supporting such antiques need to (either stick with an old version of Qt or) port the whole GNU tool-chain - which might be problematic if the GNU tool-chain is exploiting new features of modern processors in its optimisations; are you telling me the modern GNU tool-chain (modern enough to support C++11) actually continues to support the ancient architectures back to start of the century ? I'd imagine that would cripple its ability to make the most of modern processors, but I admit I don't know how the GCC suite is organised. I consider it unrealistic to claim that folk using such antiques - that have no features more recent than the 1990s - would actually care about updating the version of KDE they're running on their ancient systems; and I doubt there's been an up-to-date version of KDE that works on such antiques in the last several years. So you're complaining about us not supporting a scenario that isn't even vaguely possible to support. Or did you just forget context ? Because I also wonder how many KDE users there are on Win 7. I'm guessing it's a tiny minority of the Win 7 world. Of course, those using KDE-derived apps on Win 7 needn't be running KDE, but then the "security fixes required for inclusion in KDE" constraint isn't a problem for those versions of the apps. > You seem to be completely disconnected from how things work in the Free > Software community, and only seeing the commercial viewpoint. And you seem to be completely committed to misinterpreting everything in the lest charitable light. I just hope that's an illusion, and not your real intent. You also seem to be utterly impervious to one of the basic truths of cross-platform software support: old platforms are not free. Maintaining the existing code for the old platform comes at a cost; and adding code to support new things for the old platform comes at a cost, which is often *significantly* higher than adding the same new feature to newer platforms (because the feature is designed to make the most of what those new platforms make easy). This is just as true for Free Software projects as it is for commercial. Any project with a finite supply of developers is bound to drop support for antiques sooner or later. Eddy. ___ Development mailing list Development@qt-project.org https://lists.qt-project.org/listinfo/development
Re: [Development] Windows 7 support will be dropped in Qt 6
On Tuesday, 16 June 2020 11:15:10 PDT Ville Voutilainen wrote: > You'll get 5.15.x releases with a one-year delay from the commercial > ones. That's useless, because it means there's a one-year period in the middle with no updates. For all intents and purposes, the LTS is dead for the free software / open source community. -- Thiago Macieira - thiago.macieira (AT) intel.com Software Architect - Intel System Software Products ___ Development mailing list Development@qt-project.org https://lists.qt-project.org/listinfo/development
Re: [Development] Windows 7 support will be dropped in Qt 6
> Oddly enough, continued support for the Free Software ecosystem around > Qt is one of the things most of us who work here care about deeply, so I have no doubts that Qt engineers do. I can see this in in every code reciew and I appreciate it very much! > Our management, in any case, knows full well that the Free Software side > of the Qt ecosystem is vital to the continued viability of this company > and any business model it can realistically hope to make a living off. I doubt it. The recent decisions made by your management point into a different direction. Public communication by your top level management says something else or would you call this post https://www.qt.io/blog/qt-and-open-source "communication"? I doubt that your top level management has a sustainable strategy to nurture and expand the OS community. ___ Development mailing list Development@qt-project.org https://lists.qt-project.org/listinfo/development
Re: [Development] Windows 7 support will be dropped in Qt 6
Hi Kevin, On 16.06.2020 19:25, Kevin Kofler wrote: Edward Welbourne wrote: Kevin Kofler (16 June 2020 12:08) What "shiny new features"? All that a real-world application such as KWrite really needs from the operating system has been there at least since the 1990s, possibly since the 1970s. and I guess it's been in Qt for several releases now, so why would someone with those needs care about upgrading to Qt 6 ? Because all KDE applications will have to get ported to Qt 6 soon. You seem to be completely disconnected from how things work in the Free Software community, and only seeing the commercial viewpoint. Of course this is once again from "inside that evil company", but I want to add something here: Lots of people inside that evil company *do care* about the open source community *greatly*. There have been heated discussions about some recent decisions that have been made inside the company and there was quite some disagreement internally as well. We are not all the "evil corporate overlords" some people might envision when they see a @qt.io mail address. Having said that, the decision of dropping support Windows 7 is neither to alienate the open source community as you claim, nor to upset the commercial customers as others say. In the end it all boils down to the available "resources" and where we want/are able to spend our time. We do not have an unlimited number of developers, nor do we have infinite processing power or an infinite number of tests systems/QA engineers. We do have to decide, where development/CI/QA time is spent best independently of open source or commercial users. In an ideal world, we would have enough developers to easily maintain all the parts that are needed to have Windows 7 support. Be it in working around missing functionality, that is only available in later Windows versions or making the new graphics abstraction work on Windows 7 as well. We are not in this situation though. Our "resources" (I don't like calling developers resources :X ) are limited and Windows isn't the most loved operating system when it comes to contributions from the open source community. We did have to make a decision here. We neither targeted commercial customers nor opern source users, but we have to decide, where to spend "our time". Unfortunately Windows 7 is not a priority in this, as there still is much to be done for Qt 6 and we just do not have the number of hands to keep all these balls in the air. I guess this won't help much when it comes to calming down people, but I wanted to reiterate how we came to this decision. This really isn't about upsetting users. Olli Kevin Kofler ___ Development mailing list Development@qt-project.org https://lists.qt-project.org/listinfo/development ___ Development mailing list Development@qt-project.org https://lists.qt-project.org/listinfo/development
Re: [Development] Windows 7 support will be dropped in Qt 6
On Tue, 16 Jun 2020 at 21:04, Matthew Woehlke wrote: > >> Because all KDE applications will have to get ported to Qt 6 soon. > > Why? > ...because if they aren't, they won't get security fixes. (Because Qt 5 > is no longer maintained. Note that "LTS" isn't maintenance for Free > Software, because it won't be available. You'll get 5.15.x releases with a one-year delay from the commercial ones. If you start using it from the first of those releases, and until then, use the previous LTS before that or an earlier Qt version like 5.14, there's very little difference for you. > Also, because if they aren't, the user needs to have two complete > software stacks installed, and those stacks will likely have various > incompatibilities, or at least aesthetic inconsistencies (which are > annoying to users). (This assumes that KDE will even *allow* multiple > versions to be co-installed.) Sure, that's no different from Qt 3->4 or 4->5 transitions. My question "Why?" was mostly about "soon". ___ Development mailing list Development@qt-project.org https://lists.qt-project.org/listinfo/development
Re: [Development] Windows 7 support will be dropped in Qt 6
On 16/06/2020 13.37, Ville Voutilainen wrote: On Tue, 16 Jun 2020 at 20:27, Kevin Kofler wrote: Edward Welbourne wrote: Kevin Kofler (16 June 2020 12:08) What "shiny new features"? All that a real-world application such as KWrite really needs from the operating system has been there at least since the 1990s, possibly since the 1970s. and I guess it's been in Qt for several releases now, so why would someone with those needs care about upgrading to Qt 6 ? Because all KDE applications will have to get ported to Qt 6 soon. Why? ...because if they aren't, they won't get security fixes. (Because Qt 5 is no longer maintained. Note that "LTS" isn't maintenance for Free Software, because it won't be available. This is one of the examples where TQtC appears to have gone FLOSS-hostile. The other major one is turning into registrationware.) Also, because if they aren't, the user needs to have two complete software stacks installed, and those stacks will likely have various incompatibilities, or at least aesthetic inconsistencies (which are annoying to users). (This assumes that KDE will even *allow* multiple versions to be co-installed.) -- Matthew ___ Development mailing list Development@qt-project.org https://lists.qt-project.org/listinfo/development
Re: [Development] Windows 7 support will be dropped in Qt 6
On Tue, 16 Jun 2020 at 20:27, Kevin Kofler wrote: > > Edward Welbourne wrote: > > Kevin Kofler (16 June 2020 12:08) > >> What "shiny new features"? All that a real-world application such as > >> KWrite really needs from the operating system has been there at least > >> since the 1990s, possibly since the 1970s. > > > > and I guess it's been in Qt for several releases now, so why would > > someone with those needs care about upgrading to Qt 6 ? > > Because all KDE applications will have to get ported to Qt 6 soon. Why? > You seem to be completely disconnected from how things work in the Free > Software community, and only seeing the commercial viewpoint. (Other) Free Software projects occasionally drop old platforms and features more aggressively than Qt does. The C++ compiler you rely on will be out of upstream support in two years, and then you'll need to rely on your distribution vendor to patch it. Earlier versions of Qt are not all that different in this aspect. And new compilers won't run on any old platform you may have. Many libraries won't do that either. ___ Development mailing list Development@qt-project.org https://lists.qt-project.org/listinfo/development
Re: [Development] Windows 7 support will be dropped in Qt 6
Edward Welbourne wrote: > Kevin Kofler (16 June 2020 12:08) >> What "shiny new features"? All that a real-world application such as >> KWrite really needs from the operating system has been there at least >> since the 1990s, possibly since the 1970s. > > and I guess it's been in Qt for several releases now, so why would > someone with those needs care about upgrading to Qt 6 ? Because all KDE applications will have to get ported to Qt 6 soon. You seem to be completely disconnected from how things work in the Free Software community, and only seeing the commercial viewpoint. Kevin Kofler ___ Development mailing list Development@qt-project.org https://lists.qt-project.org/listinfo/development
Re: [Development] Windows 7 support will be dropped in Qt 6
Edward Welbourne wrote: >> So my bad, I said our product would only work on an ancient O/S or >> two, when it could indeed to made to work on a whole bunch of more >> modern systems *on which it would be irrelevant* - and thus not worth >> the significant effort of porting to, because anyone developing apps >> for those newer systems would look at our feature set and decide to >> use something that actually makes good use of the shiny new features >> of the O/S they're targeting. Kevin Kofler (16 June 2020 12:08) > What "shiny new features"? All that a real-world application such as > KWrite really needs from the operating system has been there at least > since the 1990s, possibly since the 1970s. and I guess it's been in Qt for several releases now, so why would someone with those needs care about upgrading to Qt 6 ? >> In particular, where an old O/S doesn't support some feature present in >> a newer O/S, a cross-platform toolkit that tries to provide the same >> features everywhere is left with an uncomfortable choice between >> kludging together for the old system some kind of emulation of what the >> new provides, or having a limited feature-set on the old system. At >> some point - instead of claiming to be cross-platform but failing to >> have the full feature-set on a nominally supported platform, while also >> supporting a mess of kludges to implement, for that platform, features >> every newer the O/S provides for us - it becomes more sensible (and more >> honest) to own up to not really supporting that platform any more. > Often, you will find that modern versions of GNU/Linux distributions > actually implement the desired feature using a cross-platform Free Software > library that you can just use to provide the feature on older operating > systems including proprietary ones (such as Windows 7). At least as long as > the application developer is not allergic to the LGPL for some reason. > > Of course, it depends on the individual feature, but I would need to know > what features you are talking about to go into technical details. I won't pretend to have a full over-view of Qt's feature-set, but I believe we now make use of modern graphics APIs that produce better results than the old graphics APIs they replace. For example. >> While evaluation of the pros and cons does involve garnering information >> about how users shall be affected, the means of doing that is not - nor >> should it be - having the highly self-selecting group of folk who notice >> the evaluation task "vote" on whether it's worth it or not. A broader >> overview of users is required, without the *huge* bias against change >> that this would entail. > You are making an implied assumption there that the people opposed to > breaking changes would be just a vocal minority. There is no evidence to > support that claim. No, I am not assuming that: I'm assuming that the folk who watch Jira and will notice a task proposing to take out Win 7 support are, statistically, more likely to be opposed to removal of that support than the typical user, due to a process called "selection bias". I believe that's a fairly solid assumption: and it's a strong reason to *not* interpret the minority who have commented on that issue (whether "vocal" about it or quietly) as representative of the general user-base of Qt. I also note that this minority should, of course, be listened to - just not allowed to dictate policy, as you seem to be demanding. >> Better for those working on the issue to consult sales and product >> managers, who routinely talk to a somewhat broad cross-section of users. >> Not a perfect sample, but statistically less biased than those watching >> Jira closely enough to notice this task. > That sample, on the other hand, is inherently and obviously biased against > the community using the LGPL version of Qt, because that community will > obviously never talk to your sales and product managers. As I did note, it's not a perfect sample; but it seems likely that it's less severely biased, about the question of Win 7 support, than the set of folk who happened to notice the bug you were trying to hijack as a popularity contest - which it never set out to be. There *is* a bias in the paying customers - they are better provided for by the 5.15 LTS situation - and I hope those evaluating this decision did also try to find other constituencies to hear from about it; but they should not give disproportionate attention (though they should listen) to those who were watching Jira closely for changes affecting Win 7. > But I get more and more the impression that getting rid of that > community is actually in the Qt Company's plans. Oddly enough, continued support for the Free Software ecosystem around Qt is one of the things most of us who work here care about deeply, so we tend to find it fairly thoroughly offensive when someone suggests we're trying to get rid of it - which, as a matter of legal practicality, we couldn't do
Re: [Development] Windows 7 support will be dropped in Qt 6
Edward Welbourne wrote: > So my bad, I said our product would only work on an ancient O/S or two, > when it could indeed to made to work on a whole bunch of more modern > systems *on which it would be irrelevant* - and thus not worth the > significant effort of porting to, because anyone developing apps for > those newer systems would look at our feature set and decide to use > something that actually makes good use of the shiny new features of the > O/S they're targeting. What "shiny new features"? All that a real-world application such as KWrite really needs from the operating system has been there at least since the 1990s, possibly since the 1970s. > In particular, where an old O/S doesn't support some feature present in > a newer O/S, a cross-platform toolkit that tries to provide the same > features everywhere is left with an uncomfortable choice between > kludging together for the old system some kind of emulation of what the > new provides, or having a limited feature-set on the old system. At > some point - instead of claiming to be cross-platform but failing to > have the full feature-set on a nominally supported platform, while also > supporting a mess of kludges to implement, for that platform, features > every newer the O/S provides for us - it becomes more sensible (and more > honest) to own up to not really supporting that platform any more. Often, you will find that modern versions of GNU/Linux distributions actually implement the desired feature using a cross-platform Free Software library that you can just use to provide the feature on older operating systems including proprietary ones (such as Windows 7). At least as long as the application developer is not allergic to the LGPL for some reason. Of course, it depends on the individual feature, but I would need to know what features you are talking about to go into technical details. > While evaluation of the pros and cons does involve garnering information > about how users shall be affected, the means of doing that is not - nor > should it be - having the highly self-selecting group of folk who notice > the evaluation task "vote" on whether it's worth it or not. A broader > overview of users is required, without the *huge* bias against change > that this would entail. You are making an implied assumption there that the people opposed to breaking changes would be just a vocal minority. There is no evidence to support that claim. > Better for those working on the issue to consult sales and product > managers, who routinely talk to a somewhat broad cross-section of users. > Not a perfect sample, but statistically less biased than those watching > Jira closely enough to notice this task. That sample, on the other hand, is inherently and obviously biased against the community using the LGPL version of Qt, because that community will obviously never talk to your sales and product managers. But I get more and more the impression that getting rid of that community is actually in the Qt Company's plans. Kevin Kofler ___ Development mailing list Development@qt-project.org https://lists.qt-project.org/listinfo/development
Re: [Development] Windows 7 support will be dropped in Qt 6
Edward Welbourne wrote: >> 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. Kevin Kofler (16 June 2020 01:36) > 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. Oh yes, we could indeed have a product with a last-century feature-set that still works on all the legacy operating systems and is completely irrelevant on any modern operating system where that feature-set would utterly fail to live up to the expectations of users of those more modern operating systems. Qt would still be irrelevant in this case. So my bad, I said our product would only work on an ancient O/S or two, when it could indeed to made to work on a whole bunch of more modern systems *on which it would be irrelevant* - and thus not worth the significant effort of porting to, because anyone developing apps for those newer systems would look at our feature set and decide to use something that actually makes good use of the shiny new features of the O/S they're targeting. So, same difference, sorry about phrasing it from the premise that no-one would bother porting to a newer O/S that makes the twentieth-century feature-set archaic and worthless. > 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. Sure, supporting new operating system versions doesn't require dropping support for older ones; but adding new features that make good use of what the new operating system offers - that the old did not - and enables developers to write apps that integrate with other things on the new system - in ways the old did not support - is necessary if your framework is to actually still be relevant in a few years' time, when making the most of what the O/S of the day offers is required if you're to be of any real use to the developers of new apps. If you stop being relevant to those developers, the time until you become irrelevant has started ticking down. In particular, where an old O/S doesn't support some feature present in a newer O/S, a cross-platform toolkit that tries to provide the same features everywhere is left with an uncomfortable choice between kludging together for the old system some kind of emulation of what the new provides, or having a limited feature-set on the old system. At some point - instead of claiming to be cross-platform but failing to have the full feature-set on a nominally supported platform, while also supporting a mess of kludges to implement, for that platform, features every newer the O/S provides for us - it becomes more sensible (and more honest) to own up to not really supporting that platform any more. >> 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. For reference, the actual title is: "Investigate effort/pros/cons of discontinuing Windows 7 support in Qt 6 [Spike]". Which I imagined you knew, since you first mentioned the bug, so forgive my paraphrase, I didn't see the need to repeat such a long title. > 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? While evaluation of the pros and cons does involve garnering information about how users shall be affected, the means of doing that is not - nor should it be - having the highly self-selecting group of folk who notice the evaluation task "vote" on whether it's worth it or not. A broader overview of users is required, without the *huge* bias against change that this would entail. Better for those working on the issue to consult sales and product managers, who routinely talk to a somewhat broad cross-section of users. Not a perfect sample, but statistically less biased than those watching Jira closely enough to notice this task. To be sure, "some folk aren't going to like this" is one of the cons, and surely was taken into account as such; but that gets to be balanced against the diverse pros - notably including: deleting old code that's specific to one platform reduces maintenance burden. So sure, we need to listen to those who'll be affected; but we need to listen to a broad cross-section of those affected (including those who aren't using Win 7 any more and would only gain the benefits of our development effort not being spread as thin as they would be while still trying to support Win 7 - and probably only partially support it at that, due to not managing to work out how to implement, on it, some of the shiny new things we're
Re: [Development] Windows 7 support will be dropped in Qt 6
> On 16 Jun 2020, at 02:45, Kevin Kofler wrote: > > Volker Hilsheimer wrote: >> 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! > > You are still stuck in the commercial world there. In the Free Software > world, I run a shell script that builds an .exe with cross-MinGW(-w64) and > an installer with cross-NSIS, and only if I'm really nice, I'll run the > output with WINE once for a minute or two. Then I upload it. Testing is what > I have users for. :-p > >Kevin Kofler Well, that explains why you seem to think that continuing support for old platforms while adding support for new ones is trivial (“it just works”), costs nothing (in terms of infrastructure, cost of delay for implementing new changes and using new capabilities), and should at the very least done for free ;) When you have to pay people salary and have customers that pay for a supported product, then that looks a bit different, both in terms of effort and on the balance sheet. I suppose what you describe as your QA process will about the level of QA we are going to have for Windows 7 in that Qt 6 fork then. I’d assume that you and your users/testers are going to be fine with it ;P Cheers, Volker ___ Development mailing list Development@qt-project.org https://lists.qt-project.org/listinfo/development
Re: [Development] Windows 7 support will be dropped in Qt 6
Volker Hilsheimer wrote: > 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! You are still stuck in the commercial world there. In the Free Software world, I run a shell script that builds an .exe with cross-MinGW(-w64) and an installer with cross-NSIS, and only if I'm really nice, I'll run the output with WINE once for a minute or two. Then I upload it. Testing is what I have users for. :-p Kevin Kofler ___ Development mailing list Development@qt-project.org https://lists.qt-project.org/listinfo/development
Re: [Development] Windows 7 support will be dropped in Qt 6
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 on behalf of Kevin Kofler Sent: Tuesday, June 16, 2020 1:36:54 AM To: development@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 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
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 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
Re: [Development] Windows 7 support will be dropped in Qt 6
Hi Max, I get the issues as you present them. Why drop support for the 2nd most popular OS version out there?! This also doubles the effort required for Qt developers who want to target older systems with Qt 6 apps. That is certainly a pain point! There are couple more thoughts I've had after reviewing your excellent metrics. 1. Currently Win 7 usage is declining at a little over 1% per month based on the articles you shared. This indicates that by the time Qt 6.2 (the next LTS) is released next year, Win 7 usage will most likely drop below MacOS, and further, it will be mostly gone by the time 5.15 LTS support ends (IF trends continue). This leads me to believe that the majority of Qt app developers could safely branch, or else delay migration to Qt 6 for a few more months in order to give the majority of their customers time to move with the industry. As a cross-platform framework, we do have to consider the "most common" usage scenarios first. But I can tell you understand this. 2. It may be completely possible for customers to build a version of Qt that still works with Windows 7! The key point would be that the onus moves to the Qt developers who need this support to do their own build. This is extra effort, but there seem to be only a few particular APIs that Qt is looking to remove support for. If an app doesn't use these APIs, this would not be a problem. Or you could revert a few patches and do a custom build for Win7. Ok, 3 thoughts. I think it's worth noting in addition to what Eddy shared, the Qt team did a pretty decent job of responding to the concerns raised on that QTBUG in spite of the fact that it was not intended as a feedback mechanism. We recognize that any big shift in support causes pain for the development community. Some more than others. And yet, in order to move forward we must all face the pain of evolution (to wax a little philosophical ). Making the majority of these breaks happen with a Major version release makes the most sense as it consolidates this pain into one point in time hopefully making the OVERALL experience of developing and maintaining Qt projects over time, as smooth and painless as possible. Thanks again to all our great developers for all the insightful discussion shared here! Corey Pendleton Senior Solutions Engineer, Americas -Original Message- From: Development On Behalf Of Edward Welbourne Sent: Monday, June 15, 2020 5:35 AM To: Max Paperno Cc: development@qt-project.org; inter...@qt-project.org Subject: Re: [Development] Windows 7 support will be dropped in Qt 6 Max Paperno (13 June 2020 03:28) wrote: > I would restate my objection by pointing out again [1] that Win 7 is > still the 2nd most popular desktop OS in the world, with 3x more users > than all MacOS versions combined. Never mind Linux, which is on par > with Win XP users (the previous "known good" Windows version prior to > 7). 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. 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. Meanwhile, at work, I use shiny new things so that I can deliver shiny new things to those who *do* want them; and I fix bugs in old things so that those who want stability get it. Because software developers should cater to what their users want - some of them care more about stability, others about shiny new things. In the end, giving the latter what they want today is the way to ensure the former get what they'll be wanting in a few years time (once the shiny new things have been tried, tested, fixed and made stable, while those using them have found which of them live up to their shininess and which fade too fast to be worth caring ab
Re: [Development] Windows 7 support will be dropped in Qt 6
Max Paperno (13 June 2020 03:28) wrote: > I would restate my objection by pointing out again [1] that Win 7 is > still the 2nd most popular desktop OS in the world, with 3x more users > than all MacOS versions combined. Never mind Linux, which is on par > with Win XP users (the previous "known good" Windows version prior to > 7). 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. 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. Meanwhile, at work, I use shiny new things so that I can deliver shiny new things to those who *do* want them; and I fix bugs in old things so that those who want stability get it. Because software developers should cater to what their users want - some of them care more about stability, others about shiny new things. In the end, giving the latter what they want today is the way to ensure the former get what they'll be wanting in a few years time (once the shiny new things have been tried, tested, fixed and made stable, while those using them have found which of them live up to their shininess and which fade too fast to be worth caring about). So we have stable versions and we make new versions that break old stuff in order to deliver new things - and stay relevant. > Any software publisher not catering exclusively to the "cool kids" > with the "latest and greatest" mentality would be shooting themselves > in the foot by dropping Win 7 support at this point. That's millions > of potential users. Depending on one's market, of course. And Qt won't be dropping support for Win 7, it'll still be supported by 5.15, which will have the types of change that conservative users and sysadmins are willing to take in on the machines whose O/S they're not willing to upgrade. > I would bet Qt could save a lot more resources by dropping MacOS/Linux > support entirely. Not saying that's a good idea, but dropping the 2nd > most popular OS instead doesn't make any sense to me either. Any saving is only meaningful in terms of what it lets you get instead. A platform with more *users* isn't necessarily a platform with more downloads of software previously absent from that platform, or upgrades of software previously in use. A platform whose users routinely upgrade their O/S is also a platform on which one can reasonably expect users to routinely upgrade their other software. Numbers of users are only relevant via their contribution to numbers of downloads / installs / upgrades. > Yes, anyone needing to support Win 7 can still use Qt 5, which is > what's going to happen for several more years at least. ... and that's what most users of Win 7 are likely to want; the only updates they want are security fixes. If they wanted shiny new features, they'd be upgrading the O/S, too. > I though one of the goals for Qt 6 was quicker adaptation than the Qt > 4 -> 5 migration. 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. > From this move, and everything I've seen discussed on the devs list > lately, I just don't see that happening. Seems like one breaking > change after another (even if each individual one is relatively minor, > they add up quickly). If we *never* allow ourselves breaking changes, we'd still have a nice stable
Re: [Development] Windows 7 support will be dropped in Qt 6
I would restate my objection by pointing out again [1] that Win 7 is still the 2nd most popular desktop OS in the world, with 3x more users than all MacOS versions combined. Never mind Linux, which is on par with Win XP users (the previous "known good" Windows version prior to 7). Any software publisher not catering exclusively to the "cool kids" with the "latest and greatest" mentality would be shooting themselves in the foot by dropping Win 7 support at this point. That's millions of potential users. Depending on one's market, of course. I would bet Qt could save a lot more resources by dropping MacOS/Linux support entirely. Not saying that's a good idea, but dropping the 2nd most popular OS instead doesn't make any sense to me either. Yes, anyone needing to support Win 7 can still use Qt 5, which is what's going to happen for several more years at least. I though one of the goals for Qt 6 was quicker adaptation than the Qt 4 -> 5 migration. From this move, and everything I've seen discussed on the devs list lately, I just don't see that happening. Seems like one breaking change after another (even if each individual one is relatively minor, they add up quickly). There was plenty of negative feedback left on QTBUG-74687, but it was all either ignored or dismissed. Why bother even asking people's opinion if the decision had already been made? Lastly, please everyone get off their high horse about how you're leading reluctant (or "clueless") users to a better and more secure future by "encouraging" them to "upgrade" to Win 10. There are numerous reasons NOT to switch to Win 10, especially if one actually understands how to properly handle computer security, is concerned with privacy issues, and/or just wants to get some work done instead of constantly installing forced OS updates. NVM just the hassle itself of screwing with a working system. Also I don't know what "latest features" people are talking about (from a user perspective) -- I'm definitely a computer "power user" and I can't actually name one Win 10 feature which I can't do in Win 7 (touch-centric UI being an exception in some cases, which is only useful for tablets and mostly just gets in the way on a desktop). And anyone suggesting Win 8 has clearly just never actually tried it. -Max [1]: https://bugreports.qt.io/browse/QTBUG-74687?focusedCommentId=498172#comment-498172 ___ Development mailing list Development@qt-project.org https://lists.qt-project.org/listinfo/development
