[adrianN]

A single repo makes it a bit tricky to use some library in version A for project X and version B for project Y.

[paulddraper]

Correct.

You can consider that a bad thing or a good thing.

Most language's package composition (C/C++, Java, Python, Ruby) don't permit running multiple versions at runtime. The single-version policy is one way of addressing dependency hell.

[bunderbunder]

I think that's actually a good thing. Allowing different projects to use different versions of a 3rd-party package may be convenient for developers in the short term, but it creates bigger problems in the long term.

[adrianN]

It depends on the industry. In some places changing a dependency, no matter how trivial the change, entails a lot of work. Think for example about embedded systems where deploying is a lot harder than pushing a Docker image somewhere. It is often far cheaper to analyze whether the fixed bug can be triggered to avoid upgrading unless necessary.

[bunderbunder]

In those situations, why not go ahead and keep the code up-to-date and consistent, and simply not deploy when you don't need to?

[adrianN]

Because that costs money now that could be spent on something that actually produces a profit.

[Nihilartikel]

If I recall, in Google's build system, a dependency in the source tree can be referenced at a commit ID, so you can actually have a dependency on an earlier version of artifacts in source control.

[justicezyx]

No, that's not true since at least 2013 (the year I joined Google).