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

Reply via email to