> If so, why not just call it a version conflict and fail until it's resolved? Because resolving it, in general, doesn't scale. If the dependency graph is A -

> If so, why not just call it a version conflict and fail until it's resolved? Because resolving it, in general, doesn't scale. If the dependency graph is A -> B -> D A -> C -> D B and C have to coordinate their upgrade to Dv2, so as to not break A. But B and C might not know of each other and A might not even know about their dependencies on D. Worse, C might not be able or willing to upgrade to Dv2 in the foreseeable future, for lack of bandwidth, so B is kept from upgrading to Dv2 or has to break A. If you allow both Dv1 and Dv2 to coexist, B can upgrade to Dv2, A stays unbroken and at some point, C can upgrade to Dv2 too. No need to coordinate the timing or undue rush. Now multiply that graph with a hundred dependencies and a thousand projects A, and it becomes clear that avoiding the need of coordinated upgrades is a good thing.