Per-source copyright/license notice headers that spell out copyright holder
names and years are hard to maintain and often out-of-date or plain wrong.
Precise contributor information is already maintained automatically by the
version control tool. Ultimately it is the receiver of a file who is
responsible for determining its licensing status, and per-source notices are
merely a convenience. Therefore it is simpler and more accurate for
each source to have a generic notice of the license name and references to
more detailed information on copyright holders and full license terms.
Our `Copyright.txt` file now contains a list of Contributors whose names
appeared source-level copyright notices. It also references version control
history for more precise information. Therefore we no longer need to spell
out the list of Contributors in each source file notice.
Replace CMake per-source copyright/license notice headers with a short
description of the license and links to `Copyright.txt` and online information
available from "https://cmake.org/licensing". The online URL also handles
cases of modules being copied out of our source into other projects, so we
can drop our notices about replacing links with full license text.
Run the `Utilities/Scripts/filter-notices.bash` script to perform the majority
of the replacements mechanically. Manually fix up shebang lines and trailing
newlines in a few files. Manually update the notices in a few files that the
script does not handle.
Run the `Utilities/Scripts/clang-format.bash` script to update
all our C++ code to a new style defined by `.clang-format`.
Use `clang-format` version 3.8.
* If you reached this commit for a line in `git blame`, re-run the blame
operation starting at the parent of this commit to see older history
for the content.
* See the parent commit for instructions to rebase a change across this
style transition commit.
Use a uint64_t to store encoded version numbers so we have plenty of
bits available. Encode with room for up to 1000 minor releases between
major releases and to encode dates until the year 10000 in the patch
level. This is necessary because CMake development versions prior to
release 2.8.0 used the date in the patch level, and this practice may be
restored after the 3.0 release.
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.
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.
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.
Brad King
Daniel Pfeifer
Kitware Robot
Andy Cedilnik