Reinventing versioning

Looks like Semantic Versioning 2.0.0 (SemVer, henceforth), has been riding in strides recently, being adopted by more and more projects. Don't get me wrong, having quite strict versioning specification, which can be used as a starting point to write version comparison script/app is a Good Thing™.

But, there are also quite a few issues with SemVer, as evidenced by Why Semantic Versioning Isn't, Major Release Syndrome: A Case for Chronological Versioning, Semantic Versioning Will Not Save You, and some others.

But, tl,dr; boils down to version being used to communicate breakage information, and not status of a project, which one would naturally expect, so that difference between two versions would be sort-of measure of progress made. As it is right now with SemVer, difference between versions is actually measure of breakages made, not progress. Worse, almost any change could potentially break something, even if it's not changing public API. So, now any change should bump major version. That, or it stays 0, forever.

I was looking at alternatives, looks as if every dog and its coding owner has its own, separate versioning scheme. While I'd like to use simple versioning, it seems to me that aforementioned Chronological Versioning, and Calendar Versioning, are too simple; they are good for projects with strict linear progression, such as books. As soon as project has to have two or more branches, even temporarily, scheme falls apart.

So, in the end I decided to go with what I see as a reasonable versioning. Since I didn't find any, I invented one. Version in Natural Versioning 1.0 is status of a project, just as one would expect; with optional pre-release, meta data and breakage information, all independent of each other.

For book version I adopted Chronological Versioning, quite some time ago, actually. To make book versions comparable to versions of library (and application), I put ChronoVer as a meta data into their versions, as well.