▲ | michaelt 4 days 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 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. | ||||||||
| ||||||||
▲ | 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. |