2 ms·

This seems to head into "have your cake and eat it" territory. If upstream wants people to stick with the latest and "greatest" then they need to stop breaking

This seems to head into "have your cake and eat it" territory. If upstream wants people to stick with the latest and "greatest" then they need to stop breaking APIs and ABIs at the drop of a hat. We do not live in a world where computers encased in concrete at the bottom of the ocean is a sane option for doing computing.

derefr 10y ago
> If upstream wants people to stick with the latest and "greatest" then they need to stop breaking APIs and ABIs at the drop of a hat. "Upstream" usually doesn't care about that. Upstreams—developers who write things that get packaged—almost always have a philosophy of "eh, just vendor it." Which is where things like Docker images come from. Instead, it's the distros that care about being able to update a package's deps out from under it; because this lets them have one copy of e.g. OpenSSL on the system and fix everything that depends on that package, whenever there's a new vuln discovered in it, by just updating that package. They're the ones trying to eat a cake and have it—even as the upstream devs take the view that you should just eat their ingredients directly and never bother baking a cake in the first place. :) --- As a tangent: I'm almost beginning to agree with the Golang philosophy: a "package" is its ABI. New ABI = new package with a separate identifier, that everyone has to explicitly update to. Doing this has two incentive-system effects: 1. It makes package-authors much more reluctant to make breaking changes to their ABIs, which in turn encourages them to think through their ABI before their initial release; 2. The semantics of a semver major version are transferred entirely to the package identifier itself. Almost nobody uses semver major-versions correctly; but if you collapse those semantics up a level, the package-manager can enforce the semantics. So you, as a downstream consumer, can actually be sure there are no breaking ABI changes as long as you're tracking the same package identifier.

derefr 10y ago

> If upstream wants people to stick with the latest and "greatest" then they need to stop breaking APIs and ABIs at the drop of a hat. "Upstream" usually doesn't care about that. Upstreams—developers who write things that get packaged—almost always have a philosophy of "eh, just vendor it." Which is where things like Docker images come from. Instead, it's the distros that care about being able to update a package's deps out from under it; because this lets them have one copy of e.g. OpenSSL on the system and fix everything that depends on that package, whenever there's a new vuln discovered in it, by just updating that package. They're the ones trying to eat a cake and have it—even as the upstream devs take the view that you should just eat their ingredients directly and never bother baking a cake in the first place. :) --- As a tangent: I'm almost beginning to agree with the Golang philosophy: a "package" is its ABI. New ABI = new package with a separate identifier, that everyone has to explicitly update to. Doing this has two incentive-system effects: 1. It makes package-authors much more reluctant to make breaking changes to their ABIs, which in turn encourages them to think through their ABI before their initial release; 2. The semantics of a semver major version are transferred entirely to the package identifier itself. Almost nobody uses semver major-versions correctly; but if you collapse those semantics up a level, the package-manager can enforce the semantics. So you, as a downstream consumer, can actually be sure there are no breaking ABI changes as long as you're tracking the same package identifier.