Previously the version of a develop build was only suffixed with an abbreviated commit hash within Hydrogen itself. The binaries produced by build pipelines only contained the raw target version. E.g. a binary "Hydrogen-1.2.2-win64.exe" showed version "Hydrogen-1.2.2-2a78f9c" internally. That a) may confuse users so they mistake it for an officially released version (actually happened in an issue), b) makes it harder for users/us to report the proper version used/correlate it with the underlying sources, and c) is annoying as multiple test binaries end up in the Download folder and things will be confusing.
Instead, the same version string shown internally is now also used to name all binaries produced by the build pipelines.
I did slight changes in the format of the version string:
if the target version specified in CMakeLists.txt or .appveyor matches the last tag (we are on a release branch), the git describe --tag output is used as version string. It looks very similar to our regular one but also includes the number of commits since the last tag. Which is a helpful information.
I reverted the separator between patch version and commit hash suffix from "+" to "-" again to better match the output produced by git describe --tags
In addition, the internal cmake variable DISPLAY_VERSION_PIPELINE was introduced using which the construction of a DISPLAY_VERSION within CMake can be bypassed. This is added as an auxiliary measure so the pipelines will always know the name of the created (Windows) artifacts and both the artifacts name and the version displayed inside do match.
Nevertheless, the TARGET_VERSION in .appyevor and major, minor, patch in CMakeLists.txt must still match.
Previously the version of a develop build was only suffixed with an abbreviated commit hash within Hydrogen itself. The binaries produced by build pipelines only contained the raw target version. E.g. a binary "Hydrogen-1.2.2-win64.exe" showed version "Hydrogen-1.2.2-2a78f9c" internally. That a) may confuse users so they mistake it for an officially released version (actually happened in an issue), b) makes it harder for users/us to report the proper version used/correlate it with the underlying sources, and c) is annoying as multiple test binaries end up in the Download folder and things will be confusing.
Instead, the same version string shown internally is now also used to name all binaries produced by the build pipelines.
I did slight changes in the format of the version string:
CMakeLists.txtor.appveyormatches the last tag (we are on a release branch), thegit describe --tagoutput is used as version string. It looks very similar to our regular one but also includes the number of commits since the last tag. Which is a helpful information.git describe --tagsIn addition, the internal
cmakevariableDISPLAY_VERSION_PIPELINEwas introduced using which the construction of a DISPLAY_VERSION within CMake can be bypassed. This is added as an auxiliary measure so the pipelines will always know the name of the created (Windows) artifacts and both the artifacts name and the version displayed inside do match.Nevertheless, the
TARGET_VERSIONin.appyevorand major, minor, patch inCMakeLists.txtmust still match.