@best_username_ever mentioned Semantic Versioning. It’s an actual spec. Not everyone follows it, and it doesn’t make sense for a lot of things, and far too many people are dogmatic about it. But it’s a good thing to read, and it’s not long.
A related, but not tightly coupled, spec is Changelog. Used together, and used correctly these two are nice for users.
I really like Calendar Versioning CalVer.
Gives so much more meaning to version numbers. Immediately obvious how old, and from when.
Nobody knows when Firefox 97 released. If it were
22.2you’d know it’s from February 2022.It doesn’t conflict with semver either. You can use
y.M.<release>. (I would prefer usingyy.MM.but leading 0 is not semver.)I really dislike calver for like libraries and apis. For something like Firefox it doesn’t matter as much. But for a library? I want to know if this version has breaking changes.
I’m with you; I prefer date versioning for many things. Semver does work really well for things with exposed APIs; it’s a stretch to justify using them with user tools, and especially GUI tools. Semver is used to great effect in Go - which is how it should be use: mainly by the language’s module management system. Outside of that, it’s human readable, but like XML, its main value is to machines, and only secondarily to humans.
Calendar versioning is far more human-oriented, and so more useful for things without exposed APIs or module tooling.
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.1and 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.In regular “semantic versioning” (the most popular), there is no build number.
There are no hard set rules, and it depends on what uses you have for the build number.
Making it a monotonically increasing number helps with versioning because it’s trivial to figure out which version is newer. Nevertheless, you can also rely on semantic versioning for that. It’s not like all projects are like Windows 10 and half a dozen major versions are pinned at 10.0.
You sound like you’re focusing on the wrong problem. You first need to figure it what is your versioning strategy,and from there you need to figure out if a build number plays any role on it.
I’d usually do the former because by build number I usually mean pipeline or job id in a build server. You could build 4.0.4 and then 3.4.18 and so 4.0.4 could be build number 1026 while 3.4.18 is 1027.
You can also just use a special number to keep your version number unique when doing dev builds so your version number comes through like 3.5.2-48 and some might call the 48 a build number, in which case that would make sense to reset with each version number.
It really depends on your needs. In most cases, I wouldn’t even bother.
I do have a project with a some software running on a microcontroller and a corresponding driver. I don’t record a build number, but I do record the timestamp when the build occurred. That way the driver can update the firmware if its timestamp is older than expected
The approach I’ve seen most is using semantic versioning for releases, and having a continuously upward counting (not bothering to reset) build number for everything in between.
deleted by creator
