Redefine the `CMAKE_CI_PACKAGE` pipeline schedule variable to
indicate whether it is for a development version (`dev`) or a
release version (`v[0-9]...`). Use this to automatically turn
package upload jobs on or off without having to edit the jobs
in `.gitlab-ci.yml` for release branches.
The previous wording could be misread as ensuring the arguments to the
call match the release version. Clarify that one needs to remove the
call and replace it with the literal release version string.
This helps to maximize the amount of information visible in the GitLab
web interface.
Also document their meaning in the developer documentation and in the CI
configuration file directly.
See: https://gitlab.com/gitlab-org/gitlab/-/issues/8496
Revert the change from commit 7b354baad5 (CMakeVersion: Set
CMake_VERSION_RC to 0 even in non-rc versions, 2019-07-25) and instead
define a `0` value in `CMake_VERSION_RC` to mean `-rc0`. This
distinguishes release branch versions prior to the first release
candidate from the first release candidate itself. It also makes room
for a dedicated "CMake $major.$minor.0-rc1" release commit for `-rc1` as
we have for later release candidates and final releases.
The logic that uses this value already ignores any "false" value, so `0`
is just as good as not being set at all. Using `0` for this role makes
the version components look more symmetric and reduces the number of
edits needed when creating releases.
The Maintain Current Release instructions previously assumed that
the topic branch had been merged to master. Add text to make this
explicit in the instructions as an initial verification step.
The previous instructions also made no mention of the commit
message for the merge to the release branch. This needs to include
a footer that mentions the merge request number for tracking
purposes.
Extend the maintainer guide with a reminder to self-review the
new ancestry of the `release` and `master` branches to ensure
that nothing unexpected was merged.
