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
People will be tempted to put things there for convenience, thereby
causing conflicts similar to
http://thread.gmane.org/gmane.comp.compilers.clang.devel/35162/focus=35169
where it is conceivable that the LLVM developers could put a flag on
a target for convenience, which would cause conflicts for some downstreams.
When building boost with an alternate namespace the libraries generated
will have a different naming convention. This is often done to ensure
no symbol conflicts with external libraries built against a different
version of boost. If the namespace used is "myprivateboost::" instead
of "boost::" then the libraries built will be named myprivateboost_foo
instead of boost_foo. Add an option to specify a custom namespace used
to alter the library names that get searched for.
Manually read through version control history since the 2.8.12.2
release and write release notes for important user-facing changes.
Co-Author: Stephen Kelly <steveire@gmail.com>
Starting with 3.0 we will use only two components for the feature level,
and policies are only ever introduced with a bump to the feature level
version.
4b7f2f52 Help: Add hyperlink targets for argument types in cmake-language(7)
113df227 Remove ChangeLog.manual
79f55909 Remove ChangeLog.txt
d25dbc90 Tests/BundleTest: Drop use of ChangeLog.txt
ccc87047 Help: Add documents to collect notes between releases
70309e70 Help: Add documents for release notes
34ea1f15 Utilities/Sphinx: Add option to build 'text' format
Describe the meaning of each version component in more detail in the
documentation of CMAKE_VERSION. Simplify the per-component version
variable documentation by referencing the main variable.
Include information about how to compare version strings. Also add
an historical note about the version scheme used prior to commit
v2.8.2~105^2~4 (New version scheme to support branchy workflow,
2010-04-23).
Add a release/dev.txt file and include it from release/index.rst in
development versions. Add a "Changes Since Release" section with a
toctree that globs adjacent "dev/*" documents. Add a sample topic
document explaining how topic-specific release note documents work.
This approach will allow developers to write release notes for their
changes as they are made. The release manager may then consolidate and
organize the notes for a specific release version.
Add a release/index.rst document titled "CMake Release Notes" to hold
the toctree for release notes. Add a "Release Notes" section to the
top-level html document index to link to the new document.
The old documentation stated that "all header files" were considered,
which was not true for any sensible definition of "all header files".
Only header files with certain names are considered.
Document the filename patterns matched for parsing.
4271a4ed Help: Add information about INTERFACE_AUTOUIC_OPTIONS.
7935f4de Help: Note that AUTOMOC consumes the defines and includes from targets.
2739a6f9 Help: Move Qt tool invocation information to a generic cmake-qt manual.
Add an introduction about the use of different package types, and the
ability to use Qt 4 and 5 versions together in a single buildsystem.
Add a section about automatic linking of the qtmain.lib library and
how to disable it.
Teach the project() command to set variables
{PROJECT,<PROJECT-NAME>}_VERSION{,_MAJOR,_MINOR,_PATCH,_TWEAK}
holding the project version number and its components. Add project()
command option "VERSION" to specify the version explicitly, and default
to the empty string when it is not given.
Since this clears variables when no VERSION is given, this may change
behavior for existing projects that set the version variables themselves
prior to calling project(). Add policy CMP0048 for compatibility.
Suggested-by: Alex Neundorf <neundorf@kde.org>
Teach the project() command to recognize an optional "LANGUAGES"
keyword after the project name and prior to the list of languages.
Do not allow multiple copies of the keyword. If the keyword is
specified and no languages are listed, imply NONE.
Brad King
Stephen Kelly
Chuck Atkins
Alex Merry