The author hints very briefly that Semantic Version is a hint, not a guarantee, to which I agree - but then I think we should be insisting on library maintainers that semantic versioning *should* be a guarantee, and in the worst case scenario, boycott libraries that claim to be semantically versioned but don't do it in reality.

▲

oiWecsio 4 days ago | parent | next [-]

I don't understand why major.minor.patchlevel is a "hint". It had been an interface contract with shared libraries written in C when I first touched Linux, and that was 25+ years ago; way before the term "semantic version" was even invented (AFAICT).

▲

michaelt 4 days ago | parent [-]

Imagine I make a library for loading a certain format of small, trusted configuration files.

Some guy files a CVE against my library, saying it crashes if you feed it a large, untrusted file.

I decide to put out a new version of the library, fixing the CVE by refusing to load conspicuously large files. The API otherwise remains unchanged.

Is the new release a major, minor, or bugfix release? As I have only an approximate understanding of semantic versioning norms, I could go for any of them to be honest.

Some other library authors are just as confused as me, which is why major.minor.patchlevel is only a hint.

▲

shwestrick 4 days ago | parent | next [-]

I like this example.

The client who didn't notice a difference would probably call it a bugfix.

The client whose software got ever-so-slightly more reliable probably would call it a minor update.

The client whose software previously was loading large files (luckily) without issue would call it major, because now their software just doesn't work anymore.

	▲	michaelt 4 days ago \| parent [-]
		It's also an almost-real situation (although I wasn't the library developer involved) You can Google "YAMLException: The incoming YAML document exceeds the limit" - an error introduced in response to CVE-2022-38752 - to see what happens when a library introduces a new input size limit. What happened in that case is: the updated library bumps their version from 1.31 to 1.32; then a downstream application updates their dependencies, passes all tests, and updates their version from 9.3.8.0 to 9.3.9.0

▲

oiWecsio 3 days ago | parent | prev [-]

> Imagine I make a library for loading a certain format of small, trusted configuration files.

> Some guy files a CVE against my library, saying it crashes if you feed it a large, untrusted file.

Not CVE-worthy, as the use case clearly falls outside of the documented / declared area of application.

> refusing to load conspicuously large files [...] Is the new release a major, minor, or bugfix release?

It deserves a major release, because it breaks compatibility. A capability that used to work (i.e,. loading a large but trusted file) no longer works. It may not affect everyone, but when assessing impact, we go for the most conservative evaluation.

▲

andix 4 days ago | parent | prev [-]

It can't be a guarantee. Even the smallest patches for vulnerabilities change the behavior of the code. Most of the time this is not a problem, but weird things happen all the time. Higher memory usage, slower performance, some regressions that are only relevant for a tiny amount of users, ...

	▲	SchemaLoad 4 days ago \| parent [-]
		Pretty much. Everything is a breaking change to someone. Best to just ignore sem ver and have a robust automated test suite and deployment process that minimises issues with a bad build.