That's an optimistic take on what happens in the polyrepo setup. A common alternative (I suspect by far the more common one) is that changes are made to the common area but not propagated to downstream repos, which all end up pinned to different versions of the common repo and struggle to update once they get ~years out of date.
Yeah. My experience is that the teams managing shared repos tend to shift responsibility for integrating their changes onto their users. They then also more often make breaking changes because they’re insulated from the costs of those changes.
the obvious result of that is: the changes are often not integrated for ages, if ever. Which means at some point it becomes a problem and the cost to do the integration has become much higher.
We have a person deditated to bringing in changes to our polyrepo. Nothing is considered done until it is in his mainline branches so there is incentive to get things integrated. Nothing goes in until it passes the full test suite, whith he verifies you ran before integrating and then runs again to be sure.
as someone who works on core parts that are lively to break everything I spend half of my time just integrating things and anouther quarter trying to figure out how to make my things either less core or not need changes so often.
I'd caution that a monorepo isn't a full fix to that. People often make multiple versions of libraries. You have separate 2.X and 3.X versions, with independent source code (or branches), and ask people to migrate to the new one.
There's not really a way around that when you need some behavioral change for the code using the library.
