[lifthrasiir]

Semantic Versioning requires you to declare a public API, which is not even remotely possible for many projects. If the public API surface is clear semantic versioning does indeed work well, but otherwise it doesn't give much information as users have no idea what the public API would be. Calendar versioning [1] or even a single-number version is more preferred in such situations.

[1] https://calver.org/

[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.

[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.