Ilya Fedin wrote: > I believe the fact KDE is not ported to Qt 6 yet is more question of > bureaucracy coordination of a lot of people in different KDE projects. > That is, deciding that they want to port to Qt 6 takes time, then every > project maintainer should do the port and it seems they want to > announce Qt 6 support only with KF6, it's not like GNOME that changed > version scheme to not to associate their major version with major > version of their toolkit. > > Ports themselves seem to be trivial for most of KDE frameworks from > what I saw: cmake changes, some deprecation of APIs using Qt's > deprecated APIs, etc. > > I.e. what takes the time seem to be mostly routine, coordination and > bureaucracy rather than solving big breaking changes while porting.
In practice, porting is always an issue for application developers. See, e.g., https://valdyas.org/fading/hacking/happy-porting/ (as one example out of many, and no, I am not the author of that blog post). Application developers and end users both just want their applications to keep working. No application developer wants to spend time on porting an application to a new incompatible version of a library. Any time wasted on that cannot be spent on improving the application. > A framework without major updates will stagnate. Qt 6 finally added RHI RHI can be added without breaking source and binary compatibility. In fact, that is exactly what was done in 5.14 with the introduction of the QSG_RHI environment variable. It is a behind-the-scenes change that does not need to affect the public API or ABI. > and there's still a lot of modern APIs in systems, Qt doesn't provide > cross-platform abstractions for. Adding new cross-platform abstractions for additional system APIs (modern or not) surely does not require backwards-incompatible changes to what is already there. It should just be a matter of adding a new module with a new API to Qt, without changing or removing anything existing. > I don't understand how you can ask a piece of software to not to have > major updates **indefinitely**... I am not saying that we should not have Qt releases adding new features. I am saying that we should not have (source- and/or binary-) backwards- incompatible Qt releases. I do not agree with your implied claim that a library cannot evolve without breaking existing applications. Kevin Kofler _______________________________________________ Development mailing list Development@qt-project.org https://lists.qt-project.org/listinfo/development
