[stephen-magill]

This is exactly right. Low MTTU and keeping up-to-date across the transitive dependency tree makes it less likely that vulnerabilities creep in due to those transitive dependencies. I think there's also a certain aspect of "faster is better" akin to what we see in Forsgren et al's Accelerate / State of DevOps research. If you have the team structure, development discipline, and release infrastructure required to update dependencies frequently then that probably benefits other aspects of project quality as well.

[nixpulvis]

What if your discipline is more like Debian or others who make a point to update more dependencies at the same time on a slower cadence?

[stephen-magill]

I think that works provided the cadence isn't too slow. We see an average of 8 to 12 project versions per year being published depending on ecosystem. That matches nicely with the 28 day average MTTU for 2021 in the Maven ecosystem. I wouldn't want to see projects releasing less frequently than that. But I think the right answer also depends on where in the dependency chain your project tends to live. Projects near the "leaves" should aim to update faster so that downstream consumers aren't blocked waiting on them to remediate issues. Projects more toward the base of the tree might update every month or so and not worry about releasing a new version every time a transitive dependency changes, as that would be too much version churn.

[nixpulvis]

I would really love to see these stats broken out by the type of update. Non-breaking changes (UI, interface, or otherwise) and transparent updates (filling some security holes, UI tweaks / alignment, performance, etc), though I wouldn't quite know how to mechanically label updates myself.

Basically, I'm advocating for slower user facing releases in general. We're getting overwhelmed on the flip side here.