Progressive Versioning

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.

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.

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).

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.

In case of mobile Apps, getting people to upgrade frequently is hard. I really like the approach softwares like GitHub for Windows have in checking for updates on every run and somehow forcing continuous upgrades, but it isn't suitable for non-technical audience. "The Big Reveal" seems more interesting to the App users who usually want visible improvements in exchange of their upgrade "effort", or they will become less intrigued to update to later releases.

The MAJOR number in semantic versioning, and many versioning schemes is used to signify the breaking of backwards compatibility. It doesn't mean "major new feature", think of it more as "major reworking of something you may rely on". The MINOR is used to signify new features that won't break anything in the process.

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.

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.