这不是一个编程问题，而是一个交付管道问题：
我们的产品由多个 maven 工件构建而成，这些工件每天发布快照 （2.0.1-快照），每周发布版本 （2.0.1）。在开发过程中，我们的工件会使用其他工件的快照进行全面测试，并且一切运行良好。在许多情况下，工件是同时开发的，因此相互依赖而没有向后兼容性
管道的最后阶段使用其他工件的发布版本测试特定工件的候选发布版本，因此我正在尝试发布工件 A 的 2.0.1，该版本已使用工件 B 的 2.3.5-SNAPSHOT 进行了测试并通过。如果它通过工件 A 被释放（2.0.1-SNAPSHOT 变为 2.0.1）
这是死胡同，因为工件 B 还没有发布 2.3.5（几个小时后就会发布）。所以很明显，工件 A 将在此阶段失败，因为它正在针对工件 B 的 2.3.4（这是 B 的最新版本）进行测试。
假设所有工件都具有相同的管道。
总结一下：
Artifact A is at 2.0.1-SNAPSHOT attempting to release 2.0.1, its latest release is 2.0.0
Artifact B is at 2.5.2-SNAPSHOT attempting to release 2.5.2, its latest release is 2.5.1
stage 0 test -> A 2.0.0 with B 2.5.1 - PASSED
stage 1 test -> A 2.0.1-SNAPSHOT with B 2.5.2-SNAPSHOT - PASSED
stage 2 test -> A 2.0.1-SNAPSHOT with B 2.5.1- FAILED
我知道在 B 版本 2.5.2 之前它将继续失败，但我如何在我的交付管道中考虑到这一点。我希望工件 A 能够每周发布一次。
我正在寻找的是修复我的交付管道中的这个漏洞。我是否需要管道中的另一个阶段？发布收集的快照的另一个快照？
我认为您需要确定 A 和 B 之间存在什么样的依赖关系。
如果 A 依赖 B 作为第三方库，则在测试期间切勿使用 B 的 SNAPSHOT。这样，您将永远不会被即将发布的 B 阻止。
如果 A 依赖于 B 作为多模块项目中的模块，则应手动完成 maven 的工作。这意味着你需要先构建 B 的 RELEASE，然后再构建 A 的 RELEASE。