The option replaces "--project" and allows to specify the desired string format:
- "full": The default. Prints version + suffix (e.g. "1.4.0~2021-02-14~g973cee211~snapshot").
- "version": Only prints the version (e.g. "1.4.0").
- "suffix": Only prints the suffix (e.g. "~2021-02-14~g973cee211~snapshot").
The main reason for implementing this new option is the suffix-only output.
It will be passed to CMake in a future commit, for better filename control.
This commit removes the tag logic from the script.
Its purpose was to set the name of the tag associated to the latest version as version.
It was working as expected, however in some instances we don't want the script to take the tag into account.
For example, we had to rebuild the first 1.4.0 snapshot as the version was accidentally set to 1.4.0-snapshot1.
As replacement, the "--revision" and "--type" options are implemened.
They allow to explicitly set the release type and its revision, when applicable.
Assuming the revision is set to 1 (default value), the output is currently as follows:
Type set to "snapshot": 1.4.0~2021-02-14~g973cee211~snapshot
Type set to "beta": 1.4.0-beta1
Type set to "rc": 1.4.0-rc1
Type set to "stable": 1.4.0
The option tells the script to print only the project version, i.e. "1.4.0".
This commit also makes the "--newline" argument an option and changes some text, for consistency.
The build number can be specified through the new "BUILD_NUMBER" variable.
This change is very important on Windows, for two reasons:
- It allows to easily identify binaries simply by looking at their version.
More specifically, we can guess what build they're part of.
- Right now snapshots can not be updated without uninstalling first, because the version is the same (i.e. 1.4.0).
By increasing the 4th digit of the version for every build we can solve the issue.
This commit also takes care of renaming a few variables so that they're consistent and also clearer.
For example, "version" is now "RELEASE_ID".
This commit removes all qmake-related build-files from the system. We
have now migrated to cmake and are no longer maintaining qmake anyways
and therefore there is no reason to keep it.
Removing it also clearly states to any potential user/programmer that
this project is no longer intended to be compiled with qmake.
Given that the .pri files no longer exist, the mumble-version.py script
had to be adapted to read the version from the CMakeLists.txt file
instead.
Furthermore a few of the submodules support cmake natively and therefore
we no longer need the src/buid-directory approach in order to build
them. The respective build dirs have been removed and the src-dirs have
been renamed.
Until now the snapshot versions looked something like
1.4.0~444~g4afab7c~snapshot. They include the Mumble version which they
are a snapshot for at the beginning, then the revision number (the
amount of commits since the last tag in git's history), followed by the
latest commit's hash (prefixed by "g") and finally the word "snapshot".
The problem with this approach is that it requires knowledge of the git
history at least until the most recent tag. In addition to that it also
requires someone to think about moving the "tag-for-ci" that marks a
release-state in the master branch to be set on every release.
The history requirement is not an issue for a normal clone of the
repository but if someone (e.g. the CI) performs a shallow clone of the
repository, then the script fails.
In order to address this problem, this commit changes the version format
to be 1.4.0~2020-07-02~g4afab7c67~snapshot. The revision number got
replaced by the date of the most recent commit (in ISO format) and the
commit hash is now abbreviated by git itself as it sees fit instead of
manually truncating the commit hash at 7 characters.
That way the script doesn't require knowledge of the latest tag and all
the history after that. That way the script can now be run in a shallow
clone of depth 1.
Copied from our current build environment, the header has been changed to match the one in the other scripts.
mumble-version.py determines the full Mumble version based on multiple variables, such as the current commit hash and the latest tag.
There's no reason to keep it in the build environment repository (mumble-releng), because it's supposed to be run inside the Mumble repository and doesn't depend on anything from the build environment.
