[Interest] the path forward - that 7 year thing - was, willy-nilly

Roland Hughes roland at logikalsolutions.com
Sun Mar 28 13:54:56 CEST 2021


On 3/28/21 5:00 AM, Thiago Macieira wrote:
> On Friday, 26 March 2021 17:23:38 PDT Scott Bloom wrote:
>> 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
> That's a distinction without a difference. You're saying you're unable to
> upgrade past 5.12 because a given compiler version became unsupported (that
> happened because those compilers were actually broken, not for lack of feature
> support, unlike the 5.6/5.7 change which was C++11). And you're saying the
> solution is to rename the next version 6.0.
>
> But you're not using that version, so what it is called is completely
> irrelevant. Meanwhile, those who can upgrade are thankful for not having to
> deal with the inevitable dot-oh issues.

It's a distinction that is a difference. Dropping platforms mid-major 
version is never good. Think of all the disinformation you create the 
instant you do that. There is documentation and Web pages that have 
replicated all over stating Qt 5 supports RHEL 6. You made something 
that cannot be effectively erased untrue.

What is "the process" criteria for new major version number? I'm 
curious. Why? Because I agree with Scott. Extinction of platforms needs 
to be a mandating force.

Here's what happens when you are on one of those decade+ long support 
projects.

Management: "Qt 5 supports RHEL 6 and Qt has been around twenty years so 
you will use Qt for the UI and much of the application."

Developers: "Okay. You're the boss."

Project gets developed and launched. OS cannot be changed because of all 
the custom device drivers *or said items are specifically identified in 
the clinical trial protocol.*

When y'all see "5yr MTB" listed with a hard drive, do y'all realize 
that's a SWAG? (Silly Wild Ass Guess) When entities need to know the 
_actual_ 20 or 30 year effects of something they create protocols and 
run for the entire 20-30 years required. There used to be a military 
base in OH that closed within the past decade. There was also a used DEC 
equipment vendor near there. He was always badgering the community to 
unearth working 20-30 year old equipment or new parts to fix it with. 
Why? That base was where long duration trials were being run. Of what I 
neither know nor care.

User: "I want to see this group of values on the screen in this type of 
widget"

Protocols generally only care about the test itself and how data is 
recorded in the data store. They rarely if ever care about screens for 
point in time data viewing as that is not part of the control.

If I have the wrong RHEL number, I'm sorry. I seemed to remember 6.

Management: "Well Qt 5.15 has that very widget I just saw a four-color 
glossy on it just yesterday! I'll tell the developers to do it."

Developers: "Qt 5.15 doesn't run on RHEL 6."

Management: "Qt 5 supports RHEL 6. Install Qt 5.15 and deliver the 
feature to the customer."

Developers: "Qt 5.15 doesn't run on RHEL 6."

Management: "Qt 5 supports RHEL 6. Install Qt 5.15 and deliver the 
feature to the customer."

...

> The difference, though, is this:
>
>> 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.
> Right. The lack of 5.15 updates right now is a problem.

Not for Scott.

Developers: "Qt 5.15 doesn't run on RHEL 6."

The difference is Scott and everybody else in this situation doesn't 
have to this never ending slam head against the desk conversation with 
management because they will find the last Web site never patched or 
taken down that lists RHEL 6 as being supported by Qt 5.

Whenever there is to be platform extinction the major version number 
must change so developers don't have to go through this with management 
time and time again. The same set of platforms have to work with that 
version from beginning to end.

Had the project just badged the release where extinction occurred as a 
shiny new major version with a shiny new list of supported platform (or 
just the old list with a few platforms dropped) great angst and hardship 
would be avoided by the community. The supported platform lists and 
other marketing data replicate like a virus on the Internet. When they 
are only "partially correct" or "correct until" that causes real problems.

-- 
Roland Hughes, President
Logikal Solutions
(630)-205-1593

http://www.theminimumyouneedtoknow.com
http://www.infiniteexposure.net
http://www.johnsmith-book.com
http://www.logikalblog.com
http://www.interestingauthors.com/blog



More information about the Interest mailing list