First thought when reading this article. I fell into this trap too when developing my software stuff and then realised that I was just trying to force something that didn't make sense. My apps don't contain anything that has breaking changes for anyone else. And since then I've become more pragmatic about versioning. Now I don't really bother when it comes to web apps I build. The git commit id hash is good enough for me.
If you need a version number then a very pragmatic thing to do is to just tag the repo something short and memorable once, e.g. "v1", and then use the output of "git describe --first-parent" as your version number from that point forward.
The benefit is that you get the object ID along with an automatic counter of the # of commits since the last tag, which is basically a nice, automatic version number that you only very rarely need to update (by creating a new tag).
$ git tag -m'app v1' v1
$ git describe --first-parent
v1
# hack hack hack
$ git commit -m'subsystem: some new feature'
$ git describe --first-parent
v1-1-gab2fcd9
# hack hack hack
$ git commit -m'subsystem: some other new feature'
$ git describe --first-parent
v1-2-gc37ed42
The "v1-<number>-" prefix makes it much easier for a human to understand when read in logs, since the numbers are typically incrementing, and the strings are understood by Git as valid object IDs so it's easy to lookup the commit.
I came here to mention exactly this. Being able correlate artefacts with code through embedded versions that contain the output of git describe is worth tons.
