Warning: Some posts on this platform may contain adult material intended for mature audiences only. Viewer discretion is advised. By clicking ‘Continue’, you confirm that you are 18 years or older and consent to viewing explicit content.
Something else to consider in place of or in addition to a build number could also be using the git commit hash of what you’re building. Though I would only use that for non-stable releases.
For example, stable versions of Zig look like 0.12.1 and then there’s in-development releases like 0.13.0-dev.351+64ef45eb0. It uses semantic versioning where the “pre-release” is dev.351, which includes an incrementing build number, and the “build metadata” is 64ef45eb0, the commit hash it was built from. The latter allows a user to quickly look up the exact commit easily and thus know exactly what they’re using.
Something else to consider in place of or in addition to a build number could also be using the git commit hash of what you’re building. Though I would only use that for non-stable releases.
For example, stable versions of Zig look like
0.12.1
and then there’s in-development releases like0.13.0-dev.351+64ef45eb0
. It uses semantic versioning where the “pre-release” isdev.351
, which includes an incrementing build number, and the “build metadata” is64ef45eb0
, the commit hash it was built from. The latter allows a user to quickly look up the exact commit easily and thus know exactly what they’re using.