________________________________________ >From: Development <development-boun...@qt-project.org> on behalf of apoenitz ><apoen...@t-online.de> >Sent: Friday, 14 June 2024 19:32
>There are by now ~240 QT_DEPRECATED_VERSION_X_6_* in qtbase alone. Fixing them >today involves touching thousands line of code in my code base(s). Very few of >them are truly, clearly necessary. The bulk is "nice to have" or "should have >been like that from the beginning (but the benefit is not sufficient to >the drop the original)", and a few are just pain without (significant) gain. Our biggest issue is the adoption of Qt by users moving from one major release to the next. The deprecations start to become a liability and while they keep SC compatibility in check for Qt 6 they become a serious concern for any adoption of Qt 7. While doing changes when it is necessary is OK as part of a major patch release, I totally agree with Andre that a lot of deprecations are nice to have and not mandatory. I would like to propose a far more restrictive process on when a deprecation is accepted (unless somebody has a better idea on how to curb this flood gate any other way). If you need any further prove of the seriousness of this problem, have a look at how long it took for KDE to adopt Qt 6 or look at the still incoming issues for Qt 5.15. Based on what I see, performance differences are the most common reason why Qt 6 is not ported to. The second one is the effort to port to Qt 6 due to mechanical porting from one API to the next. Qt 7 deprecations show an alarming trend and those mostly don't even involve truly needed architecture changes like potential QIODevice or QFileSystemEngine changes yet. (I only use these two classes examples to highlight the point and not that there is actual work being decided or ongoing) >As an example for the latter: QCryptographicHash::addData() went from >QByteArray plus ptr/len overload to a single addData(QByteArrayView bytes). >Most of the existing uses were of the addData(reinterpret_cast<const char >Y*(&something), sizeof(something)) kind - ugly enough already, but now it needs >an additional QByteArrayView() wrapped around. Why? Why can't the ptr/len >overload just stay? One line, inline, on the library side? Because someone >doesn't like raw pointers but a struct with a raw pointer and an int will >save the world? Based on current adoption issues with Qt 5.15, these changes constitute an alarming adoption problem for Qt 7. I cannot even argue to a customer what good this change would do to his code or even Qt. The right way should have been to add the new function, leave the old one in and remove the old one from the docs/mark it as \internal. On Friday 24 May 2024 13:29:41 GMT-3 Giuseppe D'Angelo via Development wrote: >2) We stop guaranteeing forward binary compatibility within the same >minor version. For what it is worth, I agree too. -- Alex -- Development mailing list Development@qt-project.org https://lists.qt-project.org/listinfo/development
