[Development] qsizetype

[Kevin Kofler]

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