Version numbers are for marketing and legal. They are used as a way to bundle sets of features together and give them a name "You need to upgrade to X.Y.Z, $$ plz", and "If your version is older than X.Y.Z, you are no longer supported, go away or pay us lots of money. K thx bye". Marketing may place additional rules "Customers on X.Y.Z should be able to upgrade to A.B.C by clicking a button and giving us money.", but it's still owned by marketing (or at least the person wearing that hat).<p>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.<p>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!<p>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.
Basic idea: Spread out the release of feature functionality over many "patches" (i.e. M.m.patch) rather than releasing all of feature set all at once.<p>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.
Semver versioning is expensive, it doesn't really make sense for unfunded work. "1.0" is fake security, if you want long term support you will need to acknowledge that out of band anyway. It's unfortunate that many package managers push projects into semver, because then when some dependency inevitably breaks semver semantics, far away things break - spooky action at a distance. But dependency hell is real too. Versioning is hard.<p>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.
Isn't this served by doing a pre-release? Tell people they're free to use a pre-release, but it's not guaranteed to be stable. Once you're confident it's a reliable version, bump it to stable.<p>esp-link (<a href="https://github.com/jeelabs/esp-link/releases" rel="nofollow">https://github.com/jeelabs/esp-link/releases</a>) does a great job of this. They tell you which features are in latest'n'greatest so you can try them if you wish.
I tend to use YYYY.MM.COUNTER these days (at least for projects that have frequent releases). It makes it pretty obvious how fresh or stale an installed version is, and I don't have to argue with anybody about what a feature, a bugfix or a backwards incompatible change is.
I remember the Linux kernel going from 3.X.X to 4.X.X - a change in version that didn't had that many reasons behind it. What's the point of having a distinction between major and minor version? For all I care it would be enough to have two digits: "version.patch", where if you add a feature - change version number, if you just fix something - change the patch number, that's it!