Software Engineering at Google (2020) [pdf]
I&#x27;ve maintained some pretty big libraries inside Google at one time or another in the last 16 years. I believe our system is bad for both sides (library maintainers and users). Here are some of my frustrations:<p>* the One Version Rule means that library authors can&#x27;t change a library &quot;upstream&quot;: your changes must work now or they can&#x27;t get in. This sets the bar for landing changes very high, so development moves at a snail&#x27;s pace. The version control and build system we have makes it difficult to work inside a branch, so collaboration on experimental&#x2F;new things between engineers is difficult.<p>* users can create any test they wish that exercises their integration with your library. They can depend on things you never promised (Hyrum&#x27;s law, addressed in the book). Each of these tests becomes a promise you, the library maintainer, make to that user: we will never break that test, no matter how weird it is. This is another huge burden on library maintainers.<p>* the One Version Rule means that, as a user, I can&#x27;t just pin my dependence on some software to version X. For example, if I depend on Bigtable Client, just give me version 1.4. I don&#x27;t need the meager performance improvements in version 1.5, because I don&#x27;t want to risk breaking my project. This means every roll-up release you make, every sync to HEAD you do, risks bringing in some bug in the bleeding-edge version of <i>literally everything you depend on</i>.