This is cute, but I find OpenSSL's version policy way funnier. Here I quote it verbatim from https://wiki.openssl.org/index.php/Versioning:

    *Major releases* that change one/both of the first two digits, which can break compatibility with previous versions

    *Minor releases* that change the last digit, e.g. 1.1.0 vs. 1.1.1, can and are likely to contain new features, but in a way that does not break binary compatibility. This means that an application compiled and dynamically linked with 1.1.0 does not need to be recompiled when the shared library is updated to 1.1.1. It should be noted that some features are transparent to the application such as the maximum negotiated TLS version and cipher suites, performance improvements and so on. There is no need to recompile applications to benefit from these features.

    *Letter releases,* such as 1.0.2a, exclusively contain bug and security fixes and no new features.

Oh, but what about Ruby's versioning policy, which they call "Semantic Versioning", but the semantics are:

> MINOR: increased every christmas, may be API incompatible

That's right, the semantic meaning behind minor versions is that they are released on Christmas Day. They may or may not be API compatible, who knows.

https://www.ruby-lang.org/en/news/2013/12/21/ruby-version-po...

They changed that; they are mostly (but not exactly) semver now.

https://github.com/openssl/general-policies/blob/master/poli...

> This is arguably the most important piece of software where people need to watch out for updates carefully, but its release version policy is a bit loony.

How so? That seems pretty well defined to me. Just because it's not major/minor/patch, doesn't mean that it's bad