CalVer: Calendar Versioning
This comes crashing down in a nice mudslide the exact moment you start maintaining an older stable release for fixes while also progressing on a newer version.  If anything, date codes are useful as later version number component, e.g. 4.1.0.191220.<p>Also, the &quot;When to use&quot; section is getting things quite wrong:<p><pre><code>  Does your project feature a large or constantly-changing scope?
    Large systems and frameworks, like Ubuntu and Twisted.
    Amorphous sets of utilities, like Boltons.
</code></pre>
Wrong question - relevant is: &quot;is your project the top end of the dependency chain?&quot;<p><pre><code>  Is your project time-sensitive in any way? Do other external changes drive new project releases?
    Business requirements, such as Ubuntu&#x27;s focus on support schedules.
    Security updates, such as certifi&#x27;s need to update certificates.
</code></pre>
And both of these are actually made much harder by calendaric versioning.  Administrators are already reluctant to update software for fear of breaking things.  SemVer gives extremely useful information here to establish how &quot;dangerous&quot; and update might be.  With date code versions, the admin is forced to dig through change logs, which costs time they probably don&#x27;t have, so they&#x27;ll just not update.