If Boost is really hesitant to require this of its users I recommend to collect the features that you need and require at least the latest version of CMake which brings in these features.
^This While I agree that upgrading CMake is easy, needlessly requiring the latest version is counterproductive. I know if one instance at least where I can given an example: For automated installations on HPC systems "toolchain generations" are defined. And in each generation only 1 version of each software can exist. The base is then e.g. GCC 9.3.0 and OpenMPI 4.1.0 and then software gets successively added as needed. Hence when CMake X is added and later Boost is released and that is added but requires CMake Y (with Y > X) it would mean that it cannot be used in this toolchain generation and people need to wait till the next update. So I'd focus on 2 points: - Use the CMake version that is required for what is used - Try to avoid CMake versions more recent than, say, 1 year, maybe 2. This has also the benefit that things may stabilize with patch releases. And for completeness: CMake does deprecate and eventually remove stuff. So there are (rare) instances where it is not backwards compatible. And even though often policies are used for such breaking changes, I'm quite certain even projects claiming they support CMake X do in fact not. Also note that requiring a more recent CMake enables all policies introduced until then, so behavior may change just by upgrading the required cmake version.