Semantic Versioning 2.0 (2013)

It&#x27;s really unclear from the submission here (no date in TFA either!) but v2 was &#x27;released&#x27; 10y ago fwiw.<p><a href="https:&#x2F;&#x2F;github.com&#x2F;semver&#x2F;semver&#x2F;commit&#x2F;9eca13516c58f0e9456cb2accce266fce330aaa6">https:&#x2F;&#x2F;github.com&#x2F;semver&#x2F;semver&#x2F;commit&#x2F;9eca13516c58f0e9456c...</a>

Hey folks! Don&#x27;t know why this is here. Hasn&#x27;t been many changes to semver lately. I would like to get some going, but been pretty burned out after Rust. I&#x27;d love to bring the spec in line with the implementations, so it&#x27;s gonna be a change in theory but not in practice.<p>Happy to answer any questions but won&#x27;t be around the thread for a bit.

Diff between 1.0.0 and 2.0.0<p><a href="https:&#x2F;&#x2F;github.com&#x2F;semver&#x2F;semver&#x2F;compare&#x2F;v1.0.0...v2.0.0">https:&#x2F;&#x2F;github.com&#x2F;semver&#x2F;semver&#x2F;compare&#x2F;v1.0.0...v2.0.0</a>

<a href="https:&#x2F;&#x2F;youtu.be&#x2F;oyLBGkS5ICk?si=F7R2thY7vkNbbo3a&amp;t=1800" rel="nofollow noreferrer">https:&#x2F;&#x2F;youtu.be&#x2F;oyLBGkS5ICk?si=F7R2thY7vkNbbo3a&amp;t=1800</a><p>The semantics of semantic versioning: you might be screwed

It&#x27;s 2023 and I&#x27;m still losing the battle in the workplace to build semantic versioning into each of our APIs.<p>them: &quot;Don&#x27;t worry, we compile the git commit hash in. Sometimes.&quot; me: <i>silent sobbing</i>

2.0.0... Which means they are breaking backward compatibility too.

Outside of dependencies, application code is basically<p><pre><code> 1.{infinitely_incrementing_integer} </code></pre> How many application APIs expose v2, v3, v4? You just append to v1 and add proxies to map old APIs to new ones.

The main difference appears to be about deprecation.<p>From<p>&gt; Minor version Y (x.Y.z | x &gt; 0) MUST be incremented if new, backwards compatible functionality is introduced to the public API. It MAY be incremented..<p>To<p>&gt; It MUST be incremented if any public API functionality is marked as deprecated.<p>Plus a new section on how to handle deprecating functionality.

I just wish so many libraries didn&#x27;t get compliance with SemVer by never releasing a 1.0.0

The worst apart about SemVer is that people expect that anything that LOOKS like SemVer follows the SemVer spec, however mediocre it may be. SemVer doesn&#x27;t count as an Engineering spec, its a bunch of arbitrary shit that you can or not follow, and has absolutely no meaning or enforcement.

The main problem remains not solved: <a href="https:&#x2F;&#x2F;github.com&#x2F;semver&#x2F;semver&#x2F;issues&#x2F;771">https:&#x2F;&#x2F;github.com&#x2F;semver&#x2F;semver&#x2F;issues&#x2F;771</a>