That is 100% up to every team to decide. Version numbering is completely arbitrary.
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.
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.
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
