Previously, building from a release source tarball would result in a
version string like v22.0.0-<commithash>, but we expect just v22.0.0.
This commit solves this problem.
Also use PACKAGE_VERSION instead of reconstructing it.
Removes the leading 0 from the version number. The minor version, which
we had been using as the major version, is now the major version. The
revision, which we had been using as the minor version, is now the minor
version. The revision number is dropped. The build number is promoted to
being part of the version number. This also avoids issues where it was
accidentally not included in the version number.
The CLIENT_VERSION remains the same format as previous as previously,
the Major version was 0 so that was never a factor in CLIENT_VERSION.
a71c56a clientversion: Use full commit hash for commit-based version descriptions (Luke Dashjr)
Pull request description:
git keeps changing the number of digits in abbreviated hashes, resulting in the GitHub archive hash changing because we include it here.
To workaround this and avoid hashes that become increasingly ambiguous later on, just include the full commit hash when building from git.
This has no effect on tagged releases.
(Cleanly mergable back to 0.10 without backport)
Tree-SHA512: b0be5391fadd16fbc9bbeffe1574a61c95931cbf6dea885d7e3cfcd3474b89e71767b1b55b4eeeeb66e4e119e78ff579cd9d206366d36928a209a31e1c1eed75
git keeps changing the number of digits in abbreviated hashes, resulting in the GitHub archive hash changing because we include it here.
To workaround this and avoid hashes that become increasingly ambiguous later on, just include the full commit hash when building from git.
This has no effect on tagged releases.
Putting the build date in the executable is a practice that has no place
in these days, now that deterministic building is increasingly common.
Continues #7732 which did this for the GUI.
fanquake