Am Donnerstag, 24. Oktober 2019, 10:50:07 CEST schrieb laurent Montel: > Hi, > As discussed with David previously for QT_DEPRECATED, I am against it, > because if we fix a QT/KF_DEPRECATED version we can be sure that nobody > will work for fixing deprecated method until kf6. > If we can"t see that it breaks, everybody will wait for sure (otherwise it > was already fixed). > When a compilation is broken by a new deprecated method we will fix it. > Nobody fixes a warning by default. > > I prefere to fix 1-2 deprecated methods between each new kf5 release as > fixed all deprecated method when we will port to kf6. > > And last argument it's that only me which will port deprecated method. > Because if we need to increase version in CmakeLists.txt you can be sure > that nobody will do it and if I don't do increase it nobody will do. > > So by default only me will port all deprecated method... And I don't want > it.
Laurent, you are doing great work here in making sure the gap between latest undeprecated Qt API (as well as KF API) and usage in KDE software codebase is kept small, to not collect "debts" which will be painful to pay back on the next ABI change when deprecated API will be gone. And I agree ideally more KDE contributors/maintainers would give this a thought now and then. Keeping API usage up-to-date should be part of normal code house-keeping. As you can also see by my related contributions. Just, forcing your fellow KDE contributors into also working on getting rid of deprecated API usage by said mechanism has a too big price tag, by the chance of also annoying distributions & newcomers, who very potentially that way can run into the non-building software bomb. That is not properly balanced. We have compiler warnings to point out API deprecations. Developers do see them, but want to fix them when they have time and are not busy with bugs or features, not when they are forced into it. Being forced usually results in lower quality of work, not what we want in our software, right? Cheers Friedrich
