Am Donnerstag, 24. Oktober 2019, 16:32:32 CEST schrieb Volker Krause: > On Thursday, 24 October 2019 10:50:07 CEST laurent Montel wrote: > > 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. > > There are valid arguments for both approaches. Maybe we should look at this > separately for stable branches and master? > > We don't port stable branches away from newly deprecated methods usually, > but they might still be built against newer releases of their dependencies > (think 19.08.1 against KF 5.64). So for stable branches I think it > definitely makes sense to set the disable deprecated versions to whatever > was tested at the time of branching, so they remain working going forward.
This would need some way to note that very version, so it is set automatically (no-one wants to do this manually) at branching time. Because different software has seen different working efforts, and sometimes it is hard to get rid of some deprecated API, so the trigger-version needs to be different across repos, even inside. > For master however this is less of an issue, as you say we actively port > that away from deprecated methods (and at least regarding KF5, we ideally > do that even before deprecating a method). I see it still as an issue for new-comers but also oldies who want to fix a bug in some application, for that checkout the master branch and first will have to fight a broken build, due to newer deprecated API. IMHO also git master should always be buildable, and not have planned breakage-due-to-new-deprecated-API. Cheers Friedrich
