3 ms·

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 maintainer

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 1y ago
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 1y ago
  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 1y ago
    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 1y ago
      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 1y ago
    > 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 1y ago
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 1y ago
  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.

oiWecsio 1y ago

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 1y ago
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 1y ago
  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 1y ago
    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 1y ago
  > 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 1y ago

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 1y ago
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.