On vendredi 25 octobre 2019 08:39:24 CEST Volker Krause wrote: > On Thursday, 24 October 2019 21:59:02 CEST David Faure wrote: > > On jeudi 24 octobre 2019 18:49:02 CEST Volker Krause wrote: > > > On Thursday, 24 October 2019 16:41:58 CEST David Faure wrote: > > > > > > > No such separation in KF5 itself though, there the question remains. > > > > But we have the task in our KF6 dashboard, so hopefully we won't > > > > forget > > > > to > > > > regularly increase the number and fix compilation. We as in, any KF6 > > > > volunteer, not necessarily Laurent. > > > > > > There's two things to look at for Frameworks I think: > > > - Qt: only two more version updates remaining for 5, or at most two per > > > year. Doing this as an explicit/script-assisted bump is probably > > > acceptable, and to to be sure we don't forget this it could maybe > > > automatically be determined as max(explicitly deprecated qt version, > > > minimum required qt version). > > > > I like the overall idea. Looking at implementing it though, it doesn't > > seem > > trivial to do the max() as CMakeLists.txt logic. But it doesn't have to > > be, > > this is static at any given point in time, so I'll just do that in > > release-tools/increase_qt_version.sh > > > > > - other KF5 dependencies: it might be worth setting this to the current > > > KF5 > > > version. At least at the point where we are deprecated-clean once, and > > > accept a deprecation policy that requires Frameworks to be ported before > > > the deprecation is executed. In such a scenario this would never > > > trigger, > > > but provide a safe guard we follow our own rules. > > > > Very clever. Yep, this makes a lot of sense. I'll do this too. > > In case this ends up being activated in production builds, this would > however require our ABI isn't changing by deactivating deprecated bits. > Enum values and vtable layouts look particularly in danger for this. I'm > not sure this was considered by deprecations predating the new > possibilities.
I think Friedrich took care of that when porting everything to the new macros. ABI-changing things are marked with *_BUILD_DEPRECATED_SINCE which is controlled by EXCLUDE_DEPRECATED_BEFORE_AND_AT which I'm not setting. But yeah, maybe something slipped by. Once my KF5 build with KF_DISABLE_DEPRECATED_BEFORE_AND_AT=0x053f00 is done [which requires porting 13 modules, apparently), I'll see if the rest of my Plasma session and KDE Applications (which I'm not recompiling) suffer from BIC changes :-) -- David Faure, fa...@kde.org, http://www.davidfaure.fr Working on KDE Frameworks 5
