I do this with warnings, rather than build failures (for the reproducibility issues mentioned). It's especially useful if we need to work around some immediate

I do this with warnings, rather than build failures (for the reproducibility issues mentioned). It's especially useful if we need to work around some immediate problem, which will hopefully be fixed in later versions. I don't like depending on external state, so rather than e.g. checking if a github issue is closed, I prefer to either test that the broken functionality is still broken, or else check the version number of the relevant dependency. Warnings are nice since we can choose how to handle them. Usually it's one of the following cases: - A warning appears to tell us that some workaround is no longer needed, after we just bumped 'dependency-foo' to a newer version. We can delete that workaround as part of our version bump, reducing our codebase's complexity. (Deleting the workaround has a risk of causing unexpected problems, but so does the update of dependency-foo; in fact, the out-of-date workaround itself is a risk for the update, so deleting it is usually a good idea) - A warning appears but we're rushing to hit a tight deadline. Things seem to work, so we can take a look later. (This is fine, as long as we actually do the maintenance later ;) ) - A warning appears to tell us that a dependency with known problems has been updated, so our workarounds might not be needed anymore. We try disabling the workaround, but the problem still exists in the new version; we update the check with the new version number, so the warning disappears for now but will re-appear next time that dependency changes. - A warning appears, but we can ignore it since we're building an old version of our application (e.g. to investigate a regression).