Hi, while as "culprit" for those API changes (HIG-matching rename of *YesNo* methods) I have seen to do the needed porting in some repos, there are more which need someone else to do that sadly.
Especially for those projects with many calls perhaps the approach we now developed for KDevelop might be interesting. It makes use of KMessageBox being a namespace, so can be amended to some degree: a shim/polyfill/wrapper header file named KMessageBox_KDevCompat was added, which adds the new API (as used in KDevelop) also with older KF versions, so one can use the new API without any if-version-else when including that helper header. So with the file being added in a place part of all include dirs of that project, one would just include it additionally and then use the future-proof API. --- 8< --- #include <KMessageBox> #include <KMessageBox_OurCompat> // named to be auto-sorted next to [...] // no #if KWIDGETSADDONS_VERSION vs. QT_VERSION_CHECK(5, 100, 0) here // where warningTwoActionsCancel was only added officially for 5.100 int reply = KMessageBox::warningTwoActionsCancel(...); --- 8< --- And once the min dep of your project is KF 5.100, one only has to remove those includes and the wrapper/shim/polyfill file. Makes also for a nice diff history. See https://invent.kde.org/kdevelop/kdevelop/-/merge_requests/397/ diffs#283d3562f91edb869b3331132ebb8a22bdf6ffcb (be aware, only has those methods KDevelop uses, your project might need others, but that should be straightforward, being a 1:1 API change) Cheers Friedrich