That is 100% up to every team to decide. Version numbering is completely arbitrary.
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
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.
@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.
In regular “semantic versioning” (the most popular), there is no build number.
