Sometimes I wonder if we're optimizing for the wrong things in the dependency management space: we used to have a distinction between "bleeding edge" and "stable" distribution schemes, with programmers (and users) picking the appropriate channel based on their stability and feature requires.
That seems to have been mostly discarded: we now assume that a development dependency is broken and needs to be updated if it's even slightly stale, despite being stable and working just fine. I can understand part of why that is (e.g. the overhead required to support multiple versions), but I think it's shortsighted of us to treat non-adherence to the "bleeding edge" as a security or code smell.
I think it's also tied up with security - in the past, you could have one release cycle with a stable release coming out every n releases, but now, because of vulnerabilities, larger projects usually need to have two release cycles: one for the bleeding edge, and an LTS that gets security updates ported in. That's a lot of work to maintain, so a lot of projects just nix the LTS.
Definitely, and I do not blame projects whatsoever for nixing the LTS -- it's a lot of work!
Still, I wonder about the general propriety: not every bug fix is a security fix, and treating them as such produces noise and fatigue that reduces the overall effectiveness of vulnerability reporting (since engineers become desensitized to reports).
Much of Rust's ecosystem embodies this: there are crates (like serde and clap) that have extremely regular bugfix releases, but those fixes do not (to my knowledge) surface as security concerns; instead, they're usually small invariant checks or missing trait implementations.
The ultimate reason is that security bug fixes are an absolute requirement, and unless someone is paying, most OSS providers aren't interested in doing multiple sets of bug fixes. That is the promise- and entire business model, honestly, of Red Hat, they will backport security bugfixes to your stable version.
Otherwise, since we rely so much on free software development, it kinda has to be that way.
Comments
Sometimes I wonder if we're optimizing for the wrong things in the dependency management space: we used to have a distinction between "bleeding edge" and "stable" distribution schemes, with programmers (and users) picking the appropriate channel based on their stability and feature requires.
That seems to have been mostly discarded: we now assume that a development dependency is broken and needs to be updated if it's even slightly stale, despite being stable and working just fine. I can understand part of why that is (e.g. the overhead required to support multiple versions), but I think it's shortsighted of us to treat non-adherence to the "bleeding edge" as a security or code smell.
I think it's also tied up with security - in the past, you could have one release cycle with a stable release coming out every n releases, but now, because of vulnerabilities, larger projects usually need to have two release cycles: one for the bleeding edge, and an LTS that gets security updates ported in. That's a lot of work to maintain, so a lot of projects just nix the LTS.
Definitely, and I do not blame projects whatsoever for nixing the LTS -- it's a lot of work!
Still, I wonder about the general propriety: not every bug fix is a security fix, and treating them as such produces noise and fatigue that reduces the overall effectiveness of vulnerability reporting (since engineers become desensitized to reports).
Much of Rust's ecosystem embodies this: there are crates (like serde and clap) that have extremely regular bugfix releases, but those fixes do not (to my knowledge) surface as security concerns; instead, they're usually small invariant checks or missing trait implementations.
The ultimate reason is that security bug fixes are an absolute requirement, and unless someone is paying, most OSS providers aren't interested in doing multiple sets of bug fixes. That is the promise- and entire business model, honestly, of Red Hat, they will backport security bugfixes to your stable version.
Otherwise, since we rely so much on free software development, it kinda has to be that way.