Forgot to mention this. I do not expect something that built against Qt3/4/5 to build under Qt4/5/6 on the same OS/Compiler.
If Im changing OS, or compiler. I hope to find a Qt that works on the new combo, (that’s rarely ever been an issue) but, my old version of Qt? if the major version is different, no I have no expectation. My view, I would have made Qt 5.13 (or 14) "Qt 6.0" since there were many compiler versions dropped on that version Then I would have ZERO concerns about moving to the latest and greatest Qt 5.x knowing my customers OSes would be fully supported. If there is functionality fixes that the Qt team decides needs to be put into Qt 5.x, then they may have to code them twice, one using the 5.x and once using 6.x code standards. This is what Scintilla does between 2.x and 3.x (a much smaller project of course). Scott -----Original Message----- From: Interest <interest-boun...@qt-project.org> On Behalf Of Scott Bloom Sent: Friday, March 26, 2021 17:24 To: Hamish Moffatt <ham...@risingsoftware.com>; interest@qt-project.org Subject: Re: [Interest] the path forward - that 7 year thing - was willy-nilly To be clear. Roland and I are talking about very different issues. To me, Qt should continue to support OS's/Compilers for the life of a Major version of Qt. if it built on Qt 5.0 it should build on that OS/Compiler in 5.15 If Qt decides that modern C++ was more important in 5.13, and the compilers available on an OS/Compiler are no longer compiling Qt, then frankly, its time to move to Qt 6 There are many open source tool sets, that have parallel paths for a certain time. Qt 4 is a good example. The late stage Qt4 was still being supported and new patch versions being put out as Qt 5 was rolling out. I do NOT expect to start a project in Qt3 on CentOS 3/4 (or whatever it was) to be able to trivially rebuilt in Qt 4, or 5 when I move to CentOS 7 But If Im still using Qt 5.9 LTS, and decide to move to Qt 5.15 (skipping 12), I don’t expect my OSes to no longer be supported. If there was functionality being added to 13 that made a version of a compiler/OS no longer valid to target? Make that functionality/code for Qt 6 Scott -----Original Message----- From: Interest <interest-boun...@qt-project.org> On Behalf Of Hamish Moffatt Sent: Thursday, March 25, 2021 22:06 To: interest@qt-project.org Subject: Re: [Interest] the path forward - that 7 year thing - was willy-nilly On 26/3/21 6:38 am, Roland Hughes wrote: > According to the FDA fact sheet. > > https://www.fda.gov/about-fda/fda-basics/fact-sheet-fda-glance > > There are currently 25,864 registered FDA medical device facilities. > Not one of them can change a single approved process without going > through the FDA approval process for said change. That is __NOT__ a > sprint nor is it cheap. Within the past 18 months a drug manufacturer > in high priced California put out a cattle call for a PDP 11/44 (might > have been 24) system manager. Those machines were last made around > 1978. There is a group of them still making necessary drugs in California. > > Once something is in place it stays there because it is incredibly > expensive to replace. > >> Qt's horizon is about 7 years. > That's 8 years too short. >> Anything coded to Qt 3.x needs to ported first to 4.8, before going to 5.0. >> Once you're in the 5.x series, port to 5.15 and fix the warnings. >> Once you're clean in a working build, port to Qt 6. > > There is no one who went to a good school for their IT degree where > they made the person take Cost Accounting ever going to utter that as > a valid path forward. > > There is no MBA, even from a shit school like Keller, that is going to > sign off on such a project. > I really don't understand your arguments Roland. You say you need Qt support for 15 years, but you can't actually change one bit of your software without FDA approval, so presumably this means you aren't upgrading Qt anyway. Then after 15 years you want to work on a new model of the device, starting with your existing code, and you expect it to compile with the latest Qt unchanged? Someone else was talking about support for RHEL 6. Why do you expect to use the latest Qt with an ancient OS? Is it reasonable to expect to use new Qt with an ancient OS? I see that the latest Microsoft Visual C++ compiler toolset (v142) doesn't support building for Windows XP. You can still use an older compiler. That seems like a reasonable compromise. Hamish _______________________________________________ Interest mailing list Interest@qt-project.org https://lists.qt-project.org/listinfo/interest _______________________________________________ Interest mailing list Interest@qt-project.org https://lists.qt-project.org/listinfo/interest _______________________________________________ Interest mailing list Interest@qt-project.org https://lists.qt-project.org/listinfo/interest