[cmake-developers] Preparing for CMake 3.0-rc1

Brad King brad.king at kitware.com
Fri Feb 7 13:57:28 EST 2014


On 01/27/2014 02:01 PM, Brad King wrote:
> We're past the 2014-01-15 target date for CMake 3.0 on the issue
> tracker roadmap so it is time to prepare the first release candidate.
> I will now feature-freeze master in preparation for the release.

Well it took a bit more work than I expected to update all the
release infrastructure for the new documentation system, etc.
Now we're pretty close to ready.

There is one more change I'd like to make as part of the change
to the 3.0 version number.  I propose that we drop the fourth
version component and use only two components for the feature
level.  The current three-component feature level arose for
various historical reasons, but a two-component feature level
is more consistent with the names of the components (since
<patch> does not sound like a feature change).

Through the 2.8.x release series we've used

 <major>.<minor>.<patch>[.<tweak>][-rc<n>] = Release
 <major>.<minor>.<patch>.<date>[-<id>]     = Development

As part of the bump to version 3.0 I propose we change to

 <major>.<minor>[.<patch>][-rc<n>] = Release
 <major>.<minor>.<date>[-<id>]     = Development

Post-3.0 development versions will be numbered

 3.0.CCYYMMDD, e.g. 3.0.20140501

and post-3.0 bug (regression) fix releases will be numbered

 3.0.N, e.g. 3.0.1

Future feature releases will then be numbered

 3.1, 3.2, ..., 3.9, 3.10, 3.11, ...

until an eventual 4.0.

This is now possible because the CMAKE_VERSION variable and the
if() VERSION_LESS/VERSION_EQUAL/VERSION_GREATER operators have
been around for a long time and no one should use floating-point
comparison against 3.x versions like they did long ago for 2.x.

Comments?
-Brad



More information about the cmake-developers mailing list