> I absolutely don't see how this is a problem with semver,
Strange to not see it. SemVer promises to solve dependency hell. In the example everyone correctly followed the sevmver and the app is broken by a dependency hell issue.
> it is not the responsibility of semver to tell a language how packages should be isolated and loaded. That is a problem of a) the language and b) dependency resolution in the package manager.
So semver only works for "good" languages?
> Bundler, by design, does not allow the above, instead having a flat, consistent vision of dependencies.
Ok, so what happens with the app when packages managed by Bundler get fragmented into sets depending on incompatible versions of sub-dependency (commons-logging 1.1.1 vs 2.0.1 as in the example)?
Also note, even for languages and tooling supporting multiple library versions loaded side by side, there are scenarios where things break.
Here after the "libc" module released a major version, the definition for the `void` C type in two versions of the lib are considered by the compiler as two different types, resulting in breakages everywhere around the library ecosystem.
There are also scenarios for dynamic languages / runtime errors.
> None of this is the responsibility of semver. In fact, semver would help the language provide tooling to detect that kind of "hey this instance is from foo-1.0 but you're trying to consume it in foo-2.0".
And what's next after it detected the dependency hell? It's too late and the person suffering is not in the position to fix it. You have to upgrade to "authentication 1.1.2" for security compliance, because the version 1.1.1 has known vulnerabilities. But that breaks the application, because the maintainer of the lower level dependency "commons-logging" happily breaks compatibility, proud of himself following the engineering best practice SemVer and increasing the major version number. What would you do? Leave the vulnerable lib in the app? Patch the libraries?
The promise was to prevent dependency hell, not to detect it.
Quoting the ticket and reiterating the point of my first comment above:
> Once again, the point of this ticket is to:
> 1. Remove the false promise that SemVer solves dependency hell by simply increasing major version.
> 2. Discourage unnecessary compatibility breakages, when it's trivial to maintain compatibility.
> 3. Several sentences of advice for the cases when comparability breakage is really needed.
> Ok, so what happens with the app when packages managed by Bundler get fragmented into sets depending on incompatible versions of sub-dependency (commons-logging 1.1.1 vs 2.0.1 as in the example)?
Bundler immediately yells at you, pointing out which transient dependencies are in conflict as where these dependencies come from, preventing the issue altogether.
> But that breaks the application, because the maintainer of the lower level dependency "commons-logging" happily breaks compatibility, proud of himself following the engineering best practice SemVer and increasing the major version number. What would you do? Leave the vulnerable lib in the app? Patch the libraries?
Either commons-logging backports the vulnerability on a 1.x-stable branch and does a release or it tells people to move to 2.x through and through - because many FOSS maintainers do maintain stuff on their spare time out of pure good will and cannot maintain stuff endlessly til the end of times; the dependency that continues depending on 1.x is a liability and should update to 2.x.
> Strange to not see it. SemVer promises to solve dependency hell
I would argue that it does when appropriately wielded by a competent dependency manager, I have not suffered dependency hell in Ruby for a long time. Sure there are occasional "oh there's this lib that needs an update oh wait I need to update this one oh wait it's depending on an older one oh wait this one is not compatible with ruby x.y" but I've not been hitting those for a long time, bundler doing a very good job at resolving things to compatible versions and people being largely diligent with semver (or variants and approximations thereof), and then the alternatives are:
- either you have a huge monolith dependency that does everything, IOW give up modularity
- or once a version of anything is released then breaking changes are forbidden forever, IOW give up major changes
SemVer does not solve dependency hell by itself, but it sure helps a ton in smoothing communication between library providers and consumers in a very synthetic way.
Strange to not see it. SemVer promises to solve dependency hell. In the example everyone correctly followed the sevmver and the app is broken by a dependency hell issue.
> it is not the responsibility of semver to tell a language how packages should be isolated and loaded. That is a problem of a) the language and b) dependency resolution in the package manager.
So semver only works for "good" languages?
> Bundler, by design, does not allow the above, instead having a flat, consistent vision of dependencies.
Ok, so what happens with the app when packages managed by Bundler get fragmented into sets depending on incompatible versions of sub-dependency (commons-logging 1.1.1 vs 2.0.1 as in the example)?
Also note, even for languages and tooling supporting multiple library versions loaded side by side, there are scenarios where things break.
For example, the "libc apocalypse" situation in Rust https://github.com/rust-lang/libc/issues/547
Here after the "libc" module released a major version, the definition for the `void` C type in two versions of the lib are considered by the compiler as two different types, resulting in breakages everywhere around the library ecosystem.
There are also scenarios for dynamic languages / runtime errors.
> None of this is the responsibility of semver. In fact, semver would help the language provide tooling to detect that kind of "hey this instance is from foo-1.0 but you're trying to consume it in foo-2.0".
And what's next after it detected the dependency hell? It's too late and the person suffering is not in the position to fix it. You have to upgrade to "authentication 1.1.2" for security compliance, because the version 1.1.1 has known vulnerabilities. But that breaks the application, because the maintainer of the lower level dependency "commons-logging" happily breaks compatibility, proud of himself following the engineering best practice SemVer and increasing the major version number. What would you do? Leave the vulnerable lib in the app? Patch the libraries?
The promise was to prevent dependency hell, not to detect it.
Quoting the ticket and reiterating the point of my first comment above:
> Once again, the point of this ticket is to:
> 1. Remove the false promise that SemVer solves dependency hell by simply increasing major version.
> 2. Discourage unnecessary compatibility breakages, when it's trivial to maintain compatibility.
> 3. Several sentences of advice for the cases when comparability breakage is really needed.