The split in commit v3.11.0-rc1~232^2 (CMakeVersion RC file: Split patch
into 2 components, 2017-12-01) can leave components "2018,0309", but the
latter is an octal constant with digit "9" out of range. Strip the
leading zero to express the components as "2018,309" so the resource
compiler treats them as decimal.
The binary file version has 4 16-bit components. In cases where the
patch component is too large (ex: represents a build date yyyymmdd) we
split it into two parts.
In cmVersionConfig.h we must define this macro with a value because
clients expect it to have one. Also ensure that all CMakeLists.txt
code paths have an initialized value.
Reported-by: Stephen Kelly <steveire@gmail.com>
Historically CMake used three version components for the feature level.
We released new features while incrementing only the third version
component. Since commit v2.8.2~105^2~4 (New version scheme to support
branchy workflow, 2010-04-23) we used the fourth version component for
bug-fix releases and the development date:
<major>.<minor>.<patch>[.<tweak>][-rc<n>] = Release
<major>.<minor>.<patch>.<date>[-<id>] = Development
This solidified use of three components for the feature level, and was
necessary to continue releasing 2.x versions because:
* Some existing projects performed floating-point comparisons of
${CMAKE_MAJOR_VERSION}.${CMAKE_MINOR_VERSION} to 2.x numbers
so ``x`` could never be higher than 9.
* Version 2.9.<date> was used briefly in post-2.8.0 development in
CVS prior to the transition to Git, so using it in releases may
have caused confusion.
Now that we are moving to 3.x versions, these two restrictions go away.
Therefore we now change to use only two components for the feature
level and use the scheme:
<major>.<minor>.<patch>[-rc<n>] = Release
<major>.<minor>.<date>[-<id>] = Development
Move logic to compute CMake_VERSION out of the top-level CMakeLists.txt
file to a dedicated Source/CMakeVersionCompute.cmake module and include
it from the original location. This will allow it to be re-used.
