extra-cmake-modules.git/tests/ECMSetupVersionTest, branch v5.53.0 hurd extra-cmake-modules.git Revert "Add SameMajorVersionWithPreleases compat option to ecm_setup_version." 2015-01-24T14:47:59+00:00 Alex Merry alex.merry@kde.org 2015-01-24T14:47:59+00:00 d609e598170064b4ee65392177a9d07f4302698d This reverts commit 959c374c022394a116e8ceb2b1fce2df11752068. I merged and pushed the wrong branch. 
This reverts commit 959c374c022394a116e8ceb2b1fce2df11752068.

I merged and pushed the wrong branch.
Add SameMajorVersionWithPreleases compat option to ecm_setup_version. 2015-01-24T14:45:33+00:00 Alex Merry alex.merry@kde.org 2014-12-28T15:03:07+00:00 959c374c022394a116e8ceb2b1fce2df11752068 SameMajorVersionWithPreleases is intended implement the versioning scheme followed by many KDE projects: minor releases after some high number (eg: 90) are considered to be pre-releases of the next major version, and are not compatible with the current major version. This allows alpha and beta releases to be ordered correctly by version-number-aware software like package managers (an alpha of version 2 should have a higher number than any release of version 1, but less than version 2.0). So a request for version 2.1.0 of a piece of software should not be satisfied by 2.93.4, because that is actually a pre-release of version 3. On the other hand, a request for version 2.91.0 should be satisfied by version 3.1.0. Note that prereleases are not considered unless explicitly requested, so 2.93.4 will not satisfy requests for version 3 (or version 2) of a piece of software. 
SameMajorVersionWithPreleases is intended implement the versioning
scheme followed by many KDE projects: minor releases after some high
number (eg: 90) are considered to be pre-releases of the next major
version, and are not compatible with the current major version. This
allows alpha and beta releases to be ordered correctly by
version-number-aware software like package managers (an alpha of version
2 should have a higher number than any release of version 1, but less
than version 2.0).

So a request for version 2.1.0 of a piece of software should not be
satisfied by 2.93.4, because that is actually a pre-release of version
3. On the other hand, a request for version 2.91.0 should be satisfied
by version 3.1.0.

Note that prereleases are not considered unless explicitly requested, so
2.93.4 will not satisfy requests for version 3 (or version 2) of a piece
of software.
Improve version file tests. 2014-12-28T17:30:11+00:00 Alex Merry alex.merry@kde.org 2014-12-28T16:32:13+00:00 f8af407eba5c5ea45be2c6351cf41a7cb44fed21 Mostly just refatoring to have less duplicated code. 
Mostly just refatoring to have less duplicated code.
Add COMPATIBILITY argument to ecm_setup_version(). 2014-12-28T15:03:31+00:00 Alex Merry alex.merry@kde.org 2014-12-27T15:28:39+00:00 bd69cdeea9aef1f254b7d83dd137a4de955151b7 Lots of libraries will want to use SameMajorVersion to make sure searching for version 1 of a library doesn't give you version 2, for example. We may want to add another, custom compatibility mode for KDE Frameworks-style versioning, where version x.90.z to x.99.z are alpha/beta releases for version (x+1). REVIEW: 121696 
Lots of libraries will want to use SameMajorVersion to make sure
searching for version 1 of a library doesn't give you version 2, for
example.

We may want to add another, custom compatibility mode for
KDE Frameworks-style versioning, where version x.90.z to x.99.z are
alpha/beta releases for version (x+1).

REVIEW: 121696
Fix ECMSetupVersionTest/new_explicit_header_abspath 2014-12-07T18:44:54+00:00 Alex Merry alex.merry@kde.org 2014-12-07T18:44:54+00:00 b5f3c66c8182e2ca2d0670d3e0962bc215fea220 The #include in the main.c file did not match the generated header file name, so it was actually incorrectly including the header from another test. BUG: 341576 
The #include in the main.c file did not match the generated header file
name, so it was actually incorrectly including the header from another
test.

BUG: 341576
Make ecm_setup_version interact well with CMP0048 2014-04-25T09:39:56+00:00 Alex Merry alex.merry@kde.org 2014-04-17T14:46:08+00:00 035c6fa9390ecb66422ee684be71eea692989009 When CMake policy CMP0048 (CMake 3.0) is set to NEW, the project() command is meant to manage the project's version variables. We therefore do not set the PROJECT_VERSION variables in this case. To make sure projects do not have to specify their version in multiple places, this also allows the keyword "PROJECT" to be passed to ecm_setup_version instead of an actual version number. In this case, the version passed to project() will be used. REVIEW: 117619 
When CMake policy CMP0048 (CMake 3.0) is set to NEW, the project()
command is meant to manage the project's version variables. We therefore
do not set the PROJECT_VERSION variables in this case.

To make sure projects do not have to specify their version in multiple
places, this also allows the keyword "PROJECT" to be passed to
ecm_setup_version instead of an actual version number. In this case, the
version passed to project() will be used.

REVIEW: 117619