Better would be to stop using KDEFrameworksCompilerSettings in non-KF-repos ;) See also https://marc.info/?l=kde-devel&m=161107189918853&w=2

or keeping KDEFrameworksCompilerSettings and adding it as now :) I dont want to add several lines just because there is QT_NO_FOREACH by default now. I prefer having strict flags for pim*

Just, KDEFrameworksCompilerSettings is KDEFrameworksCompilerSettings, not KDEStricterCompilerSettings. It should be able to become stricter anytime, without having to care about backward-compatibility with released software (like things in release service or on own release schedule).

Be aware that next to QT_NO_FOREACH possibly also QT_NO_KEYWORDS soon might be set by default, cmp. frameworks/extra-cmake-modules!89 (merged).

For having levels of more strictness, we need to have a dedicated solution that also includes backward-compatibility. But KDEFrameworksCompilerSettings is not designed as that solution, see reasoning in the email.

The problem is, even if we had a KDEStrictCompilerSettings, we would still have the issue of how to make it more strict without breaking released code. One solution that comes to mind is the same one that you suggested in the clang-format stuff: enabling the new stricter flags only when the requested version is the new version, which means opt-in.

Which makes me think of two solutions: maintaining both KDEFrameworksCompilerSettings and KDEStrictCompilerSettings, or simply using this version check in KDEFrameworksCompilerSettings.

Given how many kdepim libraries end up becoming frameworks in the long run, it kind of makes sense that they adopt the same settings upfront, to avoid the need for migrations to the KF way later on...

... and now I see this is exactly what you did in frameworks/extra-cmake-modules!89 (merged)

So this commit wasn't strictly necessary, right? (just trying to understand)

it's necessary as in the future we will depend against kf5.79.

Sure, but the day where you bump the ECM requirement, you would have noticed the breakage and either added QT_NO_FOREACH or ported away from foreach.

This commit prevents the surprise on that day, but in any case released code doesn't get broken.