如何使用multirepo方法管理API的版本和升级

我在一个开发不同API的团队中工作（Hadoop echosystem、scala编程语言、gradle用于依赖关系管理和交付给maven repo）。
有些API彼此之间有代码依赖关系，因为我们在不同的存储库中工作，这些API依赖于使用maven的其他API

这种方法会导致一些严重的版本同步问题：

API

A

由API

B

和

C

使用（两者都使用

A v1.0

）；API

D

正在使用

B

，

C

，因此间接依赖于

A

（从

B

，

C

）
如果我们升级到

A v2.0

，我们会发现自己正在更新

B

以使用

A v2.0

，然后更新

D

以使用较新版本的

B

，这会导致相关性错误，因为现在

D

有两个不同版本的

A

-

A v2.0

来自

B

和

A v1.0

来自

C

发生这种情况的原因是，我们无法在API版本之间进行同步，也没有适当的系统方法来手动更新直接或间接使用

a

的所有项目，甚至无法意识到它们（当您有大量API项目和依赖项时，这是一项艰巨的任务）

通过在

A

上开发，我们无法在不手动检查的情况下检查它是否与

B

、

C

、

D

集成良好，因为

A

不应该熟悉

B

、

C

、

D

，所以我们依赖于单元测试。
例如，有时我们发现

C

与

A

的新版本不兼容，因此现在我们必须发布

A

的修补程序

我们对API之间的版本没有一个真正的控制源，如果有什么东西可以自动地说哪些版本以有组织的方式彼此工作，这会有所帮助，比如：

“A”：2.0
“B”：1.4
“C”：1.2
“D”：3.0

我知道这个问题是大喊“使用MONOREPO！”，但是我们想管理一些API的旧版本并控制何时更新它们，如果我们使用MONOREPO，升级

A

将自动更新

B

，

C

，

D

，因为现在他们直接导入

A

，没有任何适当的独立版本管理。
为不同版本使用具有不同分支的monorepo也是一种选择，但管理不同分支名称的不同API的不同版本将非常困难，因为没有一种产品具有我们可以对齐的版本。
我们可以将所有不同的版本打包到一个通用API版本中，如示例3，但在一个repo中管理不同的API版本仍然很困难（实际上，在不同的repo中工作时，很难将它们逻辑地打包在一起，这是我关于如何做好的问题的一部分）

我理解，我必须接受选择monorepo/multirepo带来的一些好处和坏处，因此假设我们使用multirepo，而不是抱怨每个项目手动升级版本以及处理不兼容问题，只有询问跨多个存储库管理不同版本的更好方法，以减轻选择multirepo自动带来的一些痛苦。

总而言之，您认为由单个团队开发的跨多个repo API管理版本的最佳方法（从技术和文化角度来看，对于团队工作而言）是什么