If your library changes API all the time, do you think it's a good library?
Do you rewrite every API call in your software every time you bump dependencies?
Do you think that a library that changes API very often and thus remains insecure because bumping it breaks the program should be running on people's computers?
Why do you think libraries get any releases at all?
Software A and B depend on C (version V). A has a bug that gets fixed by shipping with C version V+1. B unfortunately has a latent bug that appears when shipping with C (version V+1).
You’re now going to have to do a bunch of work, outright not ship stuff, or even introduce bugs because of this policy!
Nobody wants buggy libraries, and in this example it’s not the library’s fault (B might just be misusing C, or in fact compensating for a bug).
Reading through these threads I’m much more empathetic to the software bill of materials argument than before as a justification for this policy. I do not think there’s an intrinsic quality argument to the global single version policy.
Bug fix releases are proof that sometimes you do really just need to put out new things to fix a bug.
> If your library changes API all the time, do you think it's a good library?
If it has a 0.x.y version number? Yes, that's what 0.x means to begin with. In fact Rust/cargo provides a stricter interpretation of semver than the original, which allows you to express guarantees of API stability (by keeping the minor version number fixed) even in 0.x-version projects.
Do you rewrite every API call in your software every time you bump dependencies?
Do you think that a library that changes API very often and thus remains insecure because bumping it breaks the program should be running on people's computers?