That is 100% up to every team to decide. Version numbering is completely arbitrary.
this post was submitted on 30 Jun 2024
17 points (77.4% liked)
Programming
17695 readers
191 users here now
Welcome to the main community in programming.dev! Feel free to post anything relating to programming here!
Cross posting is strongly encouraged in the instance. If you feel your post or another person's post makes sense in another community cross post into it.
Hope you enjoy the instance!
Rules
Rules
- Follow the programming.dev instance rules
- Keep content related to programming in some way
- If you're posting long videos try to add in some form of tldr for those who don't want to watch videos
Wormhole
Follow the wormhole through a path of communities [email protected]
founded 2 years ago
MODERATORS
Since version 3, TeX has used an idiosyncratic version numbering system, where updates have been indicated by adding an extra digit at the end of the decimal, so that the version number asymptotically approaches π. This is a reflection of the fact that TeX is now very stable, and only minor updates are anticipated. The current version of TeX is 3.141592653
Knuth has also decided that once he dies, a last version will be made which sets the version number exactly to pi.
He's gonna live a long life. Until we know pi.
He has to finish section 7.2.2 of his book
I wish. Sadly the google play store requires monotonically increasing build numbers, so any option of resetting build numbers after major releases goes out the window.
Do Google engineers get off on writing software that's only compatible within their own little world, then offering it as some de facto standard?
Google Cloud had a ton of these that make it arbitrarily hard to use.
I had lengthy discussions about that because two companies conventions collided.
We talked literally hours about the benefits of build numbers, branch specific identifiers and so on.
What conclusion did you come to?
None. The project was ultimately cancelled for unrelated reasons.
@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.2 you'd know it's from February 2022.
It doesn't conflict with semver either. You can use y.M.<release>. (I would prefer using yy.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.
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.
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.
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.