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.