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 adding at Qt 6). In particular, those given this evaluation task should not listen to "whoever shouts loudest and in their face" in preference to the many other users out there. Eddy. _______________________________________________ Development mailing list Development@qt-project.org https://lists.qt-project.org/listinfo/development