I think you're trying to make the case sound a bit more absurd than it really is, in terms of recursively scanning dependencies and checking for 100% coverage f

I think you're trying to make the case sound a bit more absurd than it really is, in terms of recursively scanning dependencies and checking for 100% coverage for all assumptions. It's really just as simple as going to the release notes and seeing if there's a mention of breaking changes or deprecations. If no such thing is mentioned then you're fine, otherwise you go and see if that change affects you at all and just take a little bit more time to test the upgrade. This has been standard practice at plenty of places that I've worked. It also doesn't mean that it makes the change a particularly good one, but I don't think I can make a bunch of OSS maintainers responsible for my own failure to review an upgrade and test it before rolling it out. In those terms, there is some culpability both with the maintainers and with the library users.