cmake_minimum_required version bump timing after CMake binary upgrade

Compatibility boundary after upgrading the CMake binary

Upgrading the CMake executable does not automatically change project behavior because cmake_minimum_required(VERSION x.y) pins the policy stack to the NEW state up to that version. The build directory, however, can become invalid when the generator or compiler metadata recorded in CMakeCache.txt no longer matches the new binary, so the documented recovery is a clean reconfigure in a fresh build tree.

Decision point: when to raise the minimum version

Raising cmake_minimum_required flips additional policies to NEW (for example, CMP0077 makes option() honor normal variables) and drops support for older CMake binaries. Third-party Find modules or vendored scripts may rely on deprecated behavior that only surfaces after the minimum version moves. Deprecation warnings in newer releases signal that very old minimums will eventually stop configuring, making the bump mandatory at some point.

Teams must weigh the risk of silent behavior changes against the maintenance burden of supporting multiple CMake versions in CI and developer environments.

• What criteria should trigger the minimum-version increase in a project that has already upgraded its CMake binary?
• How can a team verify that policy flips introduced by the new minimum do not alter the build graph or test outcomes?
• Is there a documented strategy for staging the bump across long-lived release branches without breaking downstream consumers?