From personal experience, I can attest that maintaining compiler infrastructure that builds on top of LLVM is hard over the long term. You try to compile something from a year ago with newest LLVM and find that it no longer works. The upstream LLVM developers make breaking API changes and it is the responsibility of downstream clients to fix their code accordingly.
I can only imagine the joys of keeping up with the JavaScript frontend and npm ecosystems, having mostly avoided that fun. A few months ago, I did get hit with a breaking Hugo update.
In this essay, we make a broader argument: there are opportunities in analyzing changes to software components and either certifying compatibility or detecting breaking changes. Furthermore, many programming languages techniques (formal verification through testing and of course programming language design) can contribute to the important problem of reasoning about upgrades. We survey the role of contracts and discuss how to best determine the exposed API surface of a component.
