kolan
/
CMake
1
0
Fork 0
Code Issues Pull Requests Releases Wiki Activity
CMake/Source/cmVersionConfig.h.in

16 lines
761 B
C
Raw Normal View History

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 19:43:28 +04:00
/*============================================================================
CMake - Cross Platform Makefile Generator
Copyright 2000-2009 Kitware, Inc., Insight Software Consortium
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 23:17:07 +03:00
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 19:43:28 +04:00
Distributed under the OSI-approved BSD License (the "License");
see accompanying file Copyright.txt for details.
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 23:17:07 +03:00
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 19:43:28 +04:00
This software is distributed WITHOUT ANY WARRANTY; without even the
implied warranty of MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.
See the License for more information.
============================================================================*/
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 23:17:07 +03:00
#define CMake_VERSION_MAJOR @CMake_VERSION_MAJOR@
#define CMake_VERSION_MINOR @CMake_VERSION_MINOR@
#define CMake_VERSION_PATCH @CMake_VERSION_PATCH@
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 17:44:23 +04:00
#define CMake_VERSION "@CMake_VERSION@"