[hnlmorg]

Yes! Thank you. Exactly this :)

Nearly every org I’ve worked in has used semver internally and nearly every time their version numbers were just incremented arbitrarily because there wasn’t an exposed API.

This lead to countless problems, not least of all because semver usually requires one to manually set the version number based on the change log and people are generally pretty bad at changing point releases.

So I’ve usually ended up changing the versioning scheme to build number (generated by the CI/CD tooling) plus some extra information like git hash and/or timestamp - depending on the application and whether that build information can be easily encoded as additional metadata or not.

[clhodapp]

In my opinion, Semver only makes sense for shared libraries, not for applications, or OSes, or for APIs exposed on the network.

For applications, it goes just like you said.

For APIs on the network, the caller should only get to control the breaking version their request gets routed to (the rest is abstractly owned by the service provider).

[lifthrasiir]

> Semver only makes sense for shared libraries, [...]

While it does make more sense for them, that it not even clear as it seems. Library authors rarely define the public API because it is very tedious and hard to complete---there are only some sort of fuzzy and implicit "common sense" definitions. Whenever "breaking" changes happen the definition gets stronger (but still incomplete), and over the time it would encompass every observable aspect, as the Hyrum's Law suggests.

In either case semantic versioning is not tremendously useful because either users have an incomplete expectation of what major, minor and patch versions mean, or they will be notified of every possible change and the version distinction becomes useless. Semantic versioning is still useful because it was a codification of existing practice where the expectation can be good enough to avoid most issues. There is no actual value added by the codification in my opinion.

[pseudalopex]

Many languages have explicit access levels. Others have naming conventions. Library authors use them often.

I think more software follows semantic versioning than before it was codified.

[lifthrasiir]

That's exactly my point. To my best knowledge "semantic versioning" refers to Tom Preston-Werner's codified version, which is not valuable for the aforementioned reasons. The general idea behind semantic versioning is of course valuable, but we already had a word for that... it's called versioning.

[pseudalopex]

I thought you were separating semantic versioning practices and the Semantic Versioning codification.

Versioning includes many practices outside semantic versioning obviously. Rational numbers. Odd minor version is unstable. Last number at least 90 is unstable. No patch versions. No minor versions. Incompatible minor versions. Dates.

I rejected your claim library authors rarely define the public API. And Hyrum's law makes semantic versioning imperfect but not useless.

[lifthrasiir]

Versioning is fundamentally the communication of changes to users, and those changes are inherently semantic. Semantic versioning as a general idea is thus not different from versioning as usual---one or more numbers compared in the lexicographic order relative to importance. The actual version format is at best superficial and distros have done a good job to unify all different version formats.

The Semantic Versioning codification does attach specific semantics to major, minor and patch versions, but those semantics can't exist without the public API. So the codification itself is nothing more than a stipulation that there should be three major categories of changes. The codification would have been much more useful if it included specific rules for particular languages and contexts, and there are indeed some noble attempts. But they are hardly complete and users can't rely on that. For example Rust Cargo defines a relatively complete semver guideline [1], but it doesn't define whether changing the minimum version of Rust required (MSRV) is a breaking change or not. So a minor version upgrade may or may not increase MSRV and users have to consult the release note to find it out anyway. If users can't be entirely sure if the minor version is breaking or not for their purposes, is the entire stipulation worthy?

[1] https://doc.rust-lang.org/cargo/reference/semver.html

> I rejected your claim library authors rarely define the public API.

I agree that they do think they define the public API, sometimes only in their minds, sometimes in a form of the public source code. But the source code is only a portion of the public API, and any major libraries have suffered from numerous mismatches between authors' and users' definitions of the public API. The public API in semantic versioning clearly means the latter, so my claim that library authors rarely define the public API (of the second sense) still holds. But I should have been more clear about two different notions of the public API---sorry for that.

> Hyrum's law makes semantic versioning imperfect but not useless.

The general idea, yes (you can still communicate that changes have happened). The codification, no (three-part versions are no longer useful).

[lamontcg]

Explicit access levels keep on getting eroded.

Generations of programmers come up writing web services where the router forms a hard API layer and they don't see the point in public/private/protected any more, because nobody is ever linking against their code so it doesn't matter.

[pseudalopex]

Generations of programmers wrote application code where access levels didn't matter. The concept of public and private API is relevant in web services even when language access levels aren't. And erosion is not evident to me.