Did I break you? Reverse dependency verification

This might be unpopular, but I don't think libraries should ever break backwards compatibility, at least not with enough regularity to require all of this. Sure if there is a major security thing, or something outside of your control then you might have to. But if you just want to change a function's signature, or return value, because you think it will help "clean things up" could you please just make a new function, or make it work both ways if your language allows it. I understand the desire to tear out a messy bit of code and make it beautiful, but it always leads to a bunch of headaches for little gain.

For other projects doing something similar, the Rust project has Crater (<a href="https:&#x2F;&#x2F;crater.rust-lang.org" rel="nofollow">https:&#x2F;&#x2F;crater.rust-lang.org</a>), which I believe is automatically run on betas, and can be run explicitly on PRs. But is not by default. Because it builds tens of thousands of crates using the specified compiler, and takes 3 days to complete a run.

This is a good technique, and it&#x27;s preferable to investing a bunch of effort into building a comprehensive suite of unit tests. But this technique is applicable to more than just core libraries; you can apply this to your entire stack, and to your services: Test that you don&#x27;t break your reverse dependencies, by running those reverse dependencies, like in <a href="http:&#x2F;&#x2F;catern.com&#x2F;usertests.html" rel="nofollow">http:&#x2F;&#x2F;catern.com&#x2F;usertests.html</a>

Following reverse dependencies on github (trivial with the search api for enough cases to make a difference) is something that I very very strongly wish that Pypa had done for the pip 20 resolver change. It was even suggested to them by several people, but the suggestions were dismissed because breaking countless CI toolchains across the globe was considered fine because the new resolution behavior was &quot;correct&quot;.<p>Instead we got <a href="https:&#x2F;&#x2F;github.com&#x2F;pypa&#x2F;pip&#x2F;issues&#x2F;8713" rel="nofollow">https:&#x2F;&#x2F;github.com&#x2F;pypa&#x2F;pip&#x2F;issues&#x2F;8713</a> back in August and then <a href="https:&#x2F;&#x2F;github.com&#x2F;pypa&#x2F;pip&#x2F;issues&#x2F;9187" rel="nofollow">https:&#x2F;&#x2F;github.com&#x2F;pypa&#x2F;pip&#x2F;issues&#x2F;9187</a> in November which is pinned and still open to this day.

Ok, if I understand this properly:<p>They have a core library that other projects use.<p>They want to release a new version of this core library, and upgrade all the projects to use the newer version.<p>If the CI breaks for the projects using the library, they want to catch it.<p>This still depends on the projects using the library having enough and good enough testing for something to break in the CI when this core library does something bad. That is a huge investment (having those high quality tests). The rest of this is just a script that runs the tests from those projects when people merge code into the core library, which seems like very much not a big deal.

Skimming this, because I&#x27;m in a meeting, but it reminds me of contract testing, which I&#x27;m working on implementing at work today with Pact.

Nice - I&#x27;ve been thinking stuff should work like this for a decade+