Software engineers should only care about the information required to create a reproducible build. For that, all they need is a single value, be it a number, a hex string, or a name.
Resist the temptation to let the marketing team know about the internal build numbers. That way leads to madness. We went from a single version number to a 5 digit dotted number all because people kept putting the internal number into contracts and we had to inject new releases with the same marketing number. DO NOT DO THIS - it leads to madness!
Frequently the dotted number will map onto software branches, but don't link them directly - again, that limits your flexibility and (if completely artificial) will result in unnecessary code drift when the branches inevitably diverge over 5yr+maintenance contracts.
This this this this this. This.
I've been burned by not doing this in the past with a boss who liked to make huge jumps and changes to version numbers without telling his devs, and then not being able to reproduce a given build.
Take a look at the versioning/about screens of some major software, and you'll often see these internal build numbers which have nothing to do with the shiny new "Version 2.0" that's on the branding.
Marketing can call it a Totally New Name v10, to us it's all just config values applied to build #12345.
I was occasionally tasked with gently telling a client that they didn't need to mobilise the world as the only changes to their version of the code were a few minor bug fixes. How they laughed. Not.
I, semi-seriously, suggested that, if we didn't give formal meaning to the versions, we should do client specific versioning: we sent them the release notes and they could decide whether it was minor or breaking and how much integration testing would be needed.
That way everyone could play along. Never took off.
However Semver is useful for dependency managing.
> Software engineers should only care about the information required to create a reproducible build.
You are over generalizing. While this may be true for your company/project, it is not universally true. Version numbers are used for far more than that on many open source projects. Semantic versioning is important for some dependency management tools.
On my project, our versioning is only for internal use. We use something similar to progressive versioning, but our 'progress' builds are deployed only to our staging environment for dogfooding, review and approval. Once we believe the changes are stable we deploy a new minor version. When we need to work on larger change sets that could block this process, we increment the major version and continue development and review in parallel. Using a single build number would provide us the same ability to identify what code is on what server, but it would lack the additional contextual information about where that build fits into our development process.
This is, to my experience, a pretty common way to do things. But it is a different mentality then "a feature set has to be entirely complete and have full functionality", which seemed to be the author's prior mentality.
I will be using "0.0.1-alpha.XXX" for projects with immature api, and "0.X.Y-alpha.ZZZ" for projects with mature interface but active development which may break the api, because i think this is compatible with semver package managers, right? I'm okay with people having to run -alpha in production for my small projects, i'm giving you the work for free, read the source code or don't use it.
esp-link (https://github.com/jeelabs/esp-link/releases) does a great job of this. They tell you which features are in latest'n'greatest so you can try them if you wish.
The software developer's job is to attack the features in priority order (hopefully defined by sales revenue estimates), and make sure the software is (reasonably) always releasable.
After that, it's a risk/reward, each new feature pulls in new bugs. Does the increased functionality offset the cost due to upgrade and stabilization?
