Describe The Problem To Be Solved
We currently maintain compatibility and test coverage for both CMake 3 and CMake 4. This creates additional maintenance overhead across our generated CMakeLists.txt, CI infrastructure, and test matrix.
Supporting older CMake versions has several drawbacks:
- Increased CI execution time and infrastructure cost due to maintaining multiple version combinations.
- Reduced ability to adopt modern CMake features and best practices.
- More effort required to validate changes across multiple major CMake generations.
- Continued exposure to deprecated behaviors and compatibility paths that are being removed upstream.
CMake 4 removes support for a number of legacy compatibility modes and represents the direction of the CMake ecosystem going forward. Continuing to support CMake 3 provides diminishing value while increasing maintenance burden.
Suggest A Solution
Remove support for CMake 3 and standardize development, testing, and generated build files on CMake 4.
This includes:
- Removing CMake 3 jobs from the CI matrix.
- Updating the minimum supported CMake version to a CMake 4 release.
- Updating documentation and examples to reference CMake 4.
Benefits
- Smaller and simpler maintenance surface.
- Reduced CI runtime and infrastructure requirements.
- Faster adoption of modern CMake capabilities.
- Improved consistency across supported environments.
- Alignment with the long-term direction of the CMake project.
- Reduced risk associated with legacy compatibility paths.
Optional Transition Strategy
If an immediate removal of CMake 3 support is considered too disruptive, we could introduce a deprecation phase before enforcing a CMake 4 minimum.
During this period we would continue generating projects with a CMake 3 minimum requirement while recommending CMake 4 and emitting a warning when an older version is used:
cmake_minimum_required(VERSION 3.27)
set(RECOMMENDED_CMAKE_VERSION 4.2.1)
if(CMAKE_VERSION VERSION_LESS ${RECOMMENDED_CMAKE_VERSION})
message(WARNING
"CMake ${RECOMMENDED_CMAKE_VERSION} or newer is recommended. "
"You are running version ${CMAKE_VERSION}")
endif()
This approach allows users time to upgrade while giving us visibility into the upcoming support change. After the deprecation period, the minimum required version can be raised to CMake 4 and the remaining compatibility code removed.
Describe The Problem To Be Solved
We currently maintain compatibility and test coverage for both CMake 3 and CMake 4. This creates additional maintenance overhead across our generated
CMakeLists.txt, CI infrastructure, and test matrix.Supporting older CMake versions has several drawbacks:
CMake 4 removes support for a number of legacy compatibility modes and represents the direction of the CMake ecosystem going forward. Continuing to support CMake 3 provides diminishing value while increasing maintenance burden.
Suggest A Solution
Remove support for CMake 3 and standardize development, testing, and generated build files on CMake 4.
This includes:
Benefits
Optional Transition Strategy
If an immediate removal of CMake 3 support is considered too disruptive, we could introduce a deprecation phase before enforcing a CMake 4 minimum.
During this period we would continue generating projects with a CMake 3 minimum requirement while recommending CMake 4 and emitting a warning when an older version is used:
This approach allows users time to upgrade while giving us visibility into the upcoming support change. After the deprecation period, the minimum required version can be raised to CMake 4 and the remaining compatibility code removed.