Proposal: branch ECM into ECM6 for KF6

[Friedrich W. H. Kossebau]

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