Version 5 of a software, device, vehicle or such isn’t necessarily better than version 4, and no official definition of the word “version” require this, either. If I may make another anology: You may pick one of 5 different versions of an outfit to wear, and even though they were labeled in the order they were made, from 1 to 5, none are inherently, objectively better than any other. In the case of UUIDs there are versions that are meant to supercede others, but also simply alternatives for different use-cases. Anyone with access to some up-to-date information can learn what each version’s purpose is.
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.