Support for version suffixes
CMake versions currently use a
major.minor[.patch[.tweak]] pattern, with this usage mandated by:
While this works well in most cases, it does not permit the use of informational suffixes which creates a barrier for interoperability and integration with projects which do. Would it be possible to consider changing the pattern to
major.minor[.patch[.tweak]][suffix] to allow the use of a non-numerical suffix? This could be accompanied by the addition of corresponding
_VERSION_SUFFIX variables to complement the existing numerical ones.
There are several use cases:
- Projects already using version suffixes in their workflows, to pass to
rc2etc. Indicate and communicate that the version is an unreleased work in progress, or not a final release, possibly dynamically depending on the presence or absence of a suitable git tag
-SNAPSHOT(for interoperability with maven, when a mixed Java and C++ codebase--example)
- Currently we hack both of these in by hand but it doesn't integrate with cmake's versioning in any way e.g. for packaging, target version properties, exported configuration etc.
- Third party libraries with
- Version comparison of versions with suffixes using
- for use in find_package with third-party versioning conventions
- could potentially consider the versions using an established convention such as the Debian version comparison algorithm minus the epoch and debian revision parts.
- alternatively could remain the same and ignore suffixes entirely, treating them as informational only
- Would need a modification or alternative to
- Updates to a handful of source files to add the extra variables
- Corresponding docs updates
- Most existing uses of versions will require no change; the changes would all be backward compatible since the suffix is an optional addition
Has such a change been proposed before? I would certainly not want to discourage correct use of four digit or three digit semver-style versioning by cmake or any projects using it. This proposal is primarily to aid interoperability with projects not using these conventions or where the versioning conventions are imposed by other tooling but which we have to deal with. Additionally, using the suffix for project versioning is useful in communicating the development or release status of the source in the absence of e.g. a git tag, or in a source archive lacking a tag.
If such a change would be considered acceptable, I'd be happy to work on the implementation.
Kind regards, Roger