So I wanted bring up some issues the company I work for is having using 5.12 and 5.15.
Our customers (IC development companies large and small) are extremely slow to move their OS. We had customers who are still using CentOS 6.X . These customers, often will NOT move OS’s once a project has started. If a chip is an 6-8 year project, they will often start with a 1-2 year old version of the OS (OS version migration can take 6 months or more, so they don’t change quickly even outside project constraints), and stick with it for that 6-8 years. Unfortunately, Qt has required newer and newer versions of the OSes, where we have 2 choices. We start with an OS version our customers are willing to move to (CentOS 7.0) + we build all linux library dependencies ourselves, or we stick with Qt 5.11.x. They got things working for 5.12 and 5.15, with a bunch of src (more in 5.15 obviously) based library builds. But had numerous Squish regression failures, which they are still investigating. We are hoping to get these resolved, however the team, is close to simply saying “5.11 for life”. That the lack of bug fixes/security updates will have to do, but we simply don’t have enough customers willing to move to newer versions of CentOS, but more importantly other big customers will not move, and we have to support them. I have been a Qt commercial licensee on and off (depending on the company I work for) for almost 20 years now. And I can not remember the lack of consistency between minor builds of Qt and the supported OSes. I understand the want to move to newer compilers, and somethings simply require newer features of X (high DPI support) libraries to properly support. But these decisions are really hurting Qt’s reputation in the commercial world. I’m hearing this from friends at other companies in the same industry (and similar industries). While Qt 5 is 8 years old, and the changes in C++ in that 8 years have been pretty dramatic, especially when compared to the C++ changes over Qt 4’s lifetime. Im concerned about Qt 6 taking this same view of forcing a new OS to move to later versions. I would love to see, that we treat the OS build requirements in a similar fashion to the ABI requirements are put forth. That “Minor releases are backwards binary and source compatible”. Or possibly, a push for LTS releases that are based on an OS to be supported “For the life of the major version”, meaning if you are using 5.9LTS, it will be supported as a LTS throughout 5.X since 5.12 had a significant number of OS dependency changes. And since 5.15 had a new set of OS requirements, 5.12 would also be LTS for as long as any Qt 5 is supported. A third option, is to make sure even if it prevents functionality from being supported, is to “ifdef” new compiler/OS changes out if necessary. Yes, this will be a test nightmare, but isn’t that what the commercial licenses are paying for 😊 ? I remember a number of don’t use this if not configured issues, where it wasn’t fully “not used” and still had a statically bound dependency on a shared library, but it’s a been a number of years and I cant remember the exact issue. I’m not sure what’s the best audience to bring this up, but just had a conversation with the bosses at work, and no one is happy with Qt right now because of this issue. And the “stay on 5.11” is just a horrible option but it wouldn’t surprise me if that is the choice made. Scott
_______________________________________________ Development mailing list Development@qt-project.org https://lists.qt-project.org/listinfo/development
