2 ms·

I don't think the fundamental thesis makes sense. The most time consuming part of package upgrades is most definitely coding. When a dependency gets a CVE it is

I don't think the fundamental thesis makes sense. The most time consuming part of package upgrades is most definitely coding. When a dependency gets a CVE it isn't an optional upgrade we can do somewhere down the line when it's convenient. We have to do it by the next scheduled release, or worse, before the next scheduled release. Regardless of the package, there's always changes, some of them breaking, which take considerable effort not only to implement and test, but also to identify in the first place. That's where the difficulty lies, not in planning when to upgrade what.

stevepike 3y ago
I generally agree with you, but I'd caveat that a critical CVE is easier to take if you're on the latest version of that dependency (so you can easily apply just the patch and not other changes). We want to help you weave package upgrades into ongoing maintenance rotations so that this is the case. You mentioned that implementing an upgrade is difficult because of the actual code change but also the testing and identifying what the changes are in the first place. We're starting trying to do a really good job of the last one - what are the changes in this next version, are they breaking, do they break for your codebase, and what should you do if they are? We want to move from there to automating as many of the code changes as we can, but my sense is the biggest value is in giving you the confidence that we at least captured all of the changes you need to be concerned about.