Hi, during the discussion of the MR for a KDEInstallDirs6 variant I learned that there is no clear idea yet how ECM should be be released once there are both KF5 and KF6. And more, it seems so far for ECM there is no version-branch planned, but instead would it have to support both Qt5/KF5 and Qt6/KF6 at the same time for the longer future. With no defined plan when support for Qt5/KF6 should be dropped.
Which also brings a related question: when should all the deprecated ECM modules and any other deprecated things there be dropped that have accumulated in the last years since ECM 1.0? While CMake itself has it's policy mechanism though so far I think they still keep backward compatibility for anything, just doing things different by policy default? And might only dump backward- compat support really on the next major version? So when would ECM dump backward-compat support for anything? And, due to not being co-installable to older version of itself as of now, risk breaking builds of older Qt5/KF5 software or forcing the use of dir links switching? Hello Debian and other LTS systems and trying to develop with more recent software at the same time. IMHO ECM should rather be branched into a major-version-postfixed variant as well for KF6 times, e.g. "ECM6". And allow a clear cut of legacy things, as well as some redesign where considered useful. And perhaps even be renamed, into KFCM, KDE Frameworks CMake Modules (yes, I see the unfortune brand name conflict while typing, so perhaps something else or no change at all) Having a version postfix in the name should allow co-installability. Yes, there will be some duplication, but Qt5 and Qt6 or Python 2 and Python3 libraries also duplicate lots of logic ;) and its not that the ECM modules are MB of installation. Maintenance to ensure backward ports of bug fixes between ECM & ECM6 is an issue, but might be less trouble than having to support Qt5/KF5 & Qt6/KF6 at the same time (including any cached variables on switching build deps) and then the challenge when to annoy some people by dropping legacy support they rely on. And those who want to support builds against Qt5/KF5 & Qt6/KF6 from the same code (which I personally in general recommend against, compromises needed just hurt), they then would have to do a bit more code branches in cmake code as well. But they are fine with that in the C++ code, so should they be in the cmake code (or just copy over any newer CMake modules temporarily if more simple). Also think of test setup - having to test both against Qt5 & Qt6 might be more troublesome, locally and on CI. More easy if there is just one Qt flavour to keep in mind. My 2 cents as old cmake code writer (who might not be involved in the near future) Cheers Friedrich