> (2) code that wants/needs the new functionality updates the usage at its leisure.
That's how you end up with infinite support costs in a large org. I think the point is that these changes are done atomically.
Re:Debian Git Monorepo
by sethammons on Tuesday April 02, 2024 @09:29AM
(#39905535)
that is the theory. The reality is that your team can work on fixing an issue now, but the consuming team might be able to get to it next quarter due to competing priorities. Getting multiple teams to agree to work together at the same time is much, much harder than allowing teams to update on their own schedule. You do eventually have to press the organization and deprecate the older thing.
The alternative is you do the work for them - which you may or may not have the expertise for, and the other team may not even have time for the needed code review.
Re:Debian Git Monorepo
by erik_seaberg on Tuesday April 02, 2024 @10:41PM
(#39913094)
You can't deploy a distributed system atomically, and the closer you get the more risk you're taking with prod. The old and new versions need to coexist for at least a couple of weeks in case of rollbacks.
The flow should be: (1) update a library and release it, preferring backwards compatible changes or a new major version; (2) code that wants/needs the new functionality updates the usage at its leisure. If you are having to keep multiple repos "in sync" with each other, yes, you picked the wrong abstraction. If the downstream repo(s) need to always be on the latest and greatest version of the library, the library code should be vendored with the calling code.