我正在主动将build.gradle文件转换为使用语义版本。除了使用Gradle之外，我们还使用Git并遵循Gitflow工作流程。 Jenkins用于构建项目。
已发布工件的版本遵循MAJOR.MINOR.PATCH格式。在build.gradle文件中声明依赖项时，我们使用动态版本，例如10.0。+（即采用最新的10.0.PATCH版本）。
我们将文件从Release Candidates存储库升级到Nexus中的Releases存储库。存储库的策略设置为“Releases”。由于产品的复杂性（200多个项目，具有许多上游和下游依赖项），Jenkins可用的许多促销插件似乎都不尽如人意。我们考虑让Jenkins构建主分支作为重命名工件的方法（10.0.0-rc.1-abcdefg变为10.0.0）并将它们上传到正确的Nexus存储库。
我不确定如何处理上游依赖项增加补丁版本的情况。下游项目 - 一个WAR--由Jenkins重新构建并捆绑新的JAR，但下游项目的版本不会改变。当尝试上传到Nexus时，它会失败，因为只有一个工件可以具有相同的版本。
以下是一个例子：
我可以将旧工件替换为新工件，但这意味着无法再从Nexus中的工件部署Release X（例如，在回滚的情况下，或者需要在旧版本上复制问题）释放）。
这通常如何处理？
答案 0 :(得分：0)
这通常如何处理？
我这里没有一个普遍的答案。我认为这些是最“常见”的可能性：
不要在发行版中分发依赖项，并继续使用10.0.+等依赖项版本声明。那么假设软件确实可以与任何 10.0.x版本一起使用 - 至少就你的用户所能容忍它而言。这通常发生在免费软件上，该软件在源代码或Linux发行版的软件包系统中分发。依赖性版本声明仅在依赖项需要改进时更新，即，当更改非常重要以至于您的用户不会容忍任何早期版本时。
使用该版本分发您的依赖项：
我认为核心问题是动态依赖声明 - 10.0.+版本声明。您声明的内容是您的发行版同样适用于任何 10.0.x版本。
如果确实如此，即依赖项中的修补程序修复的错误保证 从不影响发布，那么应该可能根本不会重建版本，因为它的功能无论如何都不会改变。依赖的版本无关紧要，您的版本可以保留旧的依赖版本。
但更可能的是，上游错误修正也会对您的下游项目产生影响，即它们会影响发布的功能。在这种情况下，您应该在build.gradle中明确显示“新”依赖项。由于这是对您的发布工件的更改，因此需要新版本。