logoalt Hacker News

rswail • today at 3:22 AM • 1 reply • view on HN

The original reasoning behind Semver was that it described the changes from the point of view of the consumer of the interface. If the interface didn't change, then the semver didn't change.

So yes, I am arguing it should not be used beyond that.

Horses for courses... semver is about semantic meaning to the consumer of an interface, release versioning is about configuration and SRE, user versioning is about functionality and (for a client app) security.

As for proposing the "One True Way", no, I'm not proposing that, I'm saying that I use 3 different versioning strategies for 3 different use cases.

In a production system that I am involved with, the current production is:

API: v5.0.0 (yes we just introduced major breaking changes, however, we have an endpoint for older semvers)

Release: v2025-10-30 (with release notes saying which API Semvers were available and which versions of the user app)

User app: v3.5.1 (there was a security patch to v3.5)

Replies

necovek • today at 4:19 AM

But very similar versioning schemes have been used by different software for a long time before SemVer was formalized as such: again, if you accept any user interface as the interface, vs API interface (or interfaces for developers) as you originally proposed, I have no issue with that.

Eg. GNU coding standards[1] said the following at least 18 years ago:

  You should identify each release with a pair of version numbers, a
  major version and a minor.  We have no objection to using more than
  two numbers, but it is very unlikely that you really need them.
I'd also note that your user app versioning seems to use the same approach.

[1] https://cvs.savannah.gnu.org/viewvc/gnustandards/gnustandard...

➕ show 1 reply