Commit Graph

6 Commits

Author SHA1 Message Date
Tobias Hunger af0e1cd4cb Make CMake version dirty state available to code
Set `CMake_VERSION_IS_DIRTY` to 1 or 0 depending on whether the CMake
source tree is considered dirty or not.
2016-07-14 10:35:58 -04:00
Tobias Hunger 6a077b5d63 Make CMake version suffix available to code
Make the string (e.g. "rc1" or "gSHA-dirty") available to the code.
2016-07-14 10:27:17 -04:00
Brad King 7cbab17871 Change version scheme to use only two components for feature levels
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
2014-02-19 09:30:13 -05:00
Brad King 5bfffd6f29 New version scheme to support branchy workflow
Prepare to switch to the workflow described by "git help workflows".  In
this workflow, the "master" branch is always used to integrate topics
ready for release.  Brand new work merges into a "next" branch instead.
We need a new versioning scheme to work this way because the version on
"master" must always increase.

We no longer use an even/odd minor number to distinguish releases from
development versions.  Since we still support cvs checkout of our source
tree we cannot depend on "git describe" to compute a version number
based on the history graph.  We can use the CCYYMMDD nightly date stamp
to get a monotonically increasing version component.

The new version format is "major.minor.patch.(tweak|date)".  Releases
use a tweak level in the half-open range [0,20000000), which is smaller
than any current or future date.  For tweak=0 we do not show the tweak
component, leaving the format "major.minor.patch" for most releases.
Development versions use date=CCYYMMDD for the tweak level.  The
major.minor.patch part of development versions on "master" always
matches the most recent release.

For example, a first-parent traversal of "master" might see

        v2.8.1      2.8.1.20100422    v2.8.2
           |              |              |
  ----o----o----o----o----o----o----o----o----

Since the date appears in the tweak component, the next release can
increment the patch level (or any more significant component) to be
greater than any version leading to it.  Topic branches not ready for
release are published only on "next" so we know that all versions on
master lead between two releases.
2010-04-23 09:44:23 -04:00
Brad King 96afb12087 Convert CMake to OSI-approved BSD License
This converts the CMake license to a pure 3-clause OSI-approved BSD
License.  We drop the previous license clause requiring modified
versions to be plainly marked.  We also update the CMake copyright to
cover the full development time range.
2009-09-28 11:43:28 -04:00
Brad King 98c51ff6dc ENH: Overhaul CMake version numbering
This moves the version numbers into an isolated configured header so
that not all of CMake needs to rebuild when the version changes.

Previously we had spaces, dashes and/or the word 'patch' randomly chosen
before the patch number.  Now we always report version numbers in the
traditional format "<major>.<minor>.<patch>[-rc<rc>]".

We still use odd minor numbers for development versions.  Now we also
use the CCYYMMDD date as the patch number of development versions, thus
allowing tests for exact CMake versions.
2009-03-05 15:17:07 -05:00