Hi, On 18/06/2024 10:15, Alex Blasche via Development wrote:
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)
I think this is now effectively a separate thread of discussion, since these deprecations create source incompatibilities, not binary incompatibilities.
Should we discuss it at the QtCS in a couple of slots? Thanks, -- Giuseppe D'Angelo | giuseppe.dang...@kdab.com | Senior Software Engineer KDAB (France) S.A.S., a KDAB Group company Tel. France +33 (0)4 90 84 08 53, http://www.kdab.com KDAB - Trusted Software Excellence
smime.p7s
Description: S/MIME Cryptographic Signature
-- Development mailing list Development@qt-project.org https://lists.qt-project.org/listinfo/development
