Build number issue

[Vezzra]

To describe the code someone refers to, the hash is perfect. BUT, for packaging, I need to have a version which can be ordered. I (or rather the package manager) need to know which package is newer, so I know when to update the package. The Git hash has no order. It is useless for that use case. For packaging, it is NOT sufficient.

This. And, when including the build number into the file name of installer packages, it's also far easier to tell which is the newer version. That's, after all, the whole point of build numbers being ordered.

So maybe a Build number could be "0.4.4+r<commit-count>.<git hash>"?

That wouldn't be a build number anymore, but a version number. Not exactly the same, a build number should identify a specific build all by itself, without the need to specify a version.

Not sure if the "+" works, as in: the relevant package managers understand that 0.4.4 < 0.4.4+ < 0.4.5.

With an ordered build number that's not part of a version number no problem at all.

[Chriss]

I don't think I understand the difference between a version number and the build number... Or what a build really is... Maybe because for my use case, the version is the important part... I mean, in Arch, with source packages, everyone builds their own binary. So the binary and when it's being built is not so important as the code version that is being built.

[Dilvish]

That wouldn't be a build number anymore, but a version number. Not exactly the same, a build number should identify a specific build all by itself, without the need to specify a version.

I wasn't quite really making sense of this, and so tried searching around for typical meanings for 'build number' and it seems to me that it is most often used for the portion of the version number after the minor version number, or at least that's where it would be designated (pretty much just where we are talking about it). So I'm still not understanding what objection you were making here.