Is Semantic Versioning an Anti-Pattern?
I started using semver about two years ago in two of my projects---one a library and another an application.  For my library, the versions run (output from &quot;git tag -n&quot;):<p><pre><code>    6.3.0           Bump version number to 6.3.0.
    6.3.1           The &quot;Remake the Makefile&quot; Version
    6.3.2           Bug fix---use $(RM) instead of &#x2F;bin&#x2F;rm
    6.3.3           Bug fix---the &quot;all&quot; target does not depend upon &quot;depend&quot;.
    6.3.4           Bug fix---add restrict to some parameters.
    6.3.5           Bug fix---fix compiler warnings from CLang.
    6.3.6           Bug fix---guard against some possibly undefined defines.
    6.3.7           Bug fix---update dependencies in Makefile
    6.4.0           The &quot;Trees For The Nodes&quot; Version
    6.5.0           The &quot;PairListCreate()&quot; Version
    6.6.0           The &quot;Go for Gopher URLs&quot; Version
    6.6.1           Bug fix---use c99 instead of gcc
    6.6.2           Bug fix---use $(DESTDIR) when installing
    6.6.3           Bug fix---replace malloc()&#x2F;memset() pair with calloc()
    6.7.0           The &quot;Christmas Cleanup&quot; Version
    6.8.0           The &quot;Breaking Up Is Hard To Do&quot; Version
    6.8.1           Bug fix---potential buffer overwrite.
    6.8.2           Bug fix---add missing headerfile.
</code></pre>
No APIs have changed, but each X.Y.0 has added new functions (with the exception of 6.8.0, which changed the source layout but not the API one bit), and each .n release has been a bug fix.  I don&#x27;t have much of an issue with semver for library code.<p>For the application, I&#x27;ve found semver not to be much of a win.  The versions:<p><pre><code>    v4.6.0          The &#x27;XXXX FaceGoogleMyTwitterPlusSpaceBook&#x27; Version
    v4.6.1          Bug fix---double free
    v4.6.2          Bug fix---if not using email notification, code doesn&#x27;t compile
    v4.6.3          Bug fix---don&#x27;t use _IO_cookie_io_functions_t
    v4.6.4          Bug fix---potential double free (yet again).
    v4.6.5          Bug fix---encoded entries via email mess things up.
    v4.6.6          Bug fix---unauthorized person posting via email leads to double fclose()
    v4.6.7          Bug fix---a NULL tumbler crashes the program.
    v4.7.0          The &#x27;Tumblers Reloaded&#x27; Version
    v4.7.1          Bug fix---date checking on exiting tumbler_new() was borked.
    v4.7.2          Bug fix---previous and last calculations were borked.
    v4.7.3          Bug fix---check tumbler date(s) against last entry, not the current time
    v4.7.4          Bug fix---current link was wrong
    v4.7.5          Bug fix---the assert() when comparing dates was wrong
    v4.8.0          The &#x27;Constant Upgrade&#x27; Version
    v4.9.0          The &#x27;Unused API Paramters&#x27; Version
    v4.9.1          Bug fix---getline() called with incorrect parameters.
    v4.9.2          Bug fix---dependencies got out of whack.
    v4.9.3          Bug fix---used the wrong name when generating the tarball.
    v4.9.4          Bug fix---removed compiler warnings under different compiler options.
    v4.9.5          Bug fix---assert() was too assertive.
    v4.9.6          Bug fix---I was a bit too assertive in the callback code.
    v4.9.7          Bug fix---fix header guards.
    v4.10.0         The &#x27;Spiffier Email&#x27; Version
    v4.11.0         The &#x27;Go For Gopher&#x27; Version
    v4.11.1         Bug fix---potential memory leaks fixed
    v4.11.2         Bug fix---notify_emaillist() was borked
    v4.11.3         Bug fix---memory corruption
    v4.12.0         The &quot;Somewhat Arbitrary Christmas Release&quot; Version
    v4.13.0         The &quot;Target Advertisers&quot; Version
</code></pre>
In actual use, the &quot;version numbers&quot; could very well be 6.0, 6.1, 6.2, 11.1, 11.2, etc. for all the meaning of &quot;4&quot; has (largly---this is the codebase after the 4th major reworking of the code---it&#x27;s a 17 year old code base).  I could see a separate semver standard for applications---basically an X.P model---version, bug fix.  Or perhaps a D.X.P model---data format, version, bug fix.  If the saved data format changes, change the D number.