gradle - 在上游依赖项已更改时促进语义版本化的工件

Question

我正在进行一项将我们的build.gradle文件转换为使用语义版本的计划。除了使用Gradle之外，我们还使用Git并遵循Gitflow工作流程。 Jenkins用于构建项目。

发布的 Artifact 的版本遵循MAJOR.MINOR.PATCH格式。在build.gradle文件中声明依赖项时，我们使用动态版本，例如10.0。+(即采用最新的10.0.PATCH版本)。

我们将 Artifact 从Release Candidates存储库升级到Nexus中的Releases存储库。存储库的策略设置为“发布”。由于产品的复杂性(200多个项目，并且有许多上游和下游依赖项)，许多可用于Jenkins的促销插件似乎都不够用。我们正在考虑让Jenkins构建master分支，以重命名 Artifact (10.0.0-rc.1-abcdefg变为10.0.0)并将其上载到正确的Nexus存储库。

我不确定如何处理上游依赖项补丁版本增加的情况。下游项目-WAR-由 Jenkins (Jenkins)重建并 bundle 了新的JAR，但下游项目的版本未更改。尝试上传到Nexus时，它失败，因为只有一个 Artifact 可以具有相同版本。

这是一个例子:

Releases Nexus存储库的上游API版本为10.0.0，下游项目版本为10.0.0

下游项目取决于上游API的10.0。+

Upper-api.jar bundle 到下游-project.war文件

中

这两个 Artifact 作为产品

的发行版X的一部分进行部署

将修补程序分支合并到master后，上游API版本已更改为10.0.1

该修复程序意味着在部署后，该产品现在为Release X'

下游项目保持在10.0.0，但由于上游依赖项

的变化而被重新构建

Jenkins无法将下游项目10.0.0.war上传到Nexus，因为它已经存在

我可以将旧的 Artifact 替换为新的 Artifact ，但这意味着不能再从Nexus中的 Artifact 部署Release X(例如，在回滚的情况下，或者需要在较旧的版本上复制问题)。

通常如何处理？

Answer 1

How is this typically handled?

我在这里没有一个普遍的答案。我认为这些是最“常见”的可能性:

不要在发行版中分发您的依赖项，而是继续使用依赖项版本声明，例如10.0.+。当时的假设是，该软件确实可以与任何10.0.x版本一起使用-至少在用户可以容忍的范围内。对于在源代码或Linux发行版的软件包系统中分发的自由软件，通常会发生这种情况。仅当对依赖项有必要的改进时，即当更改非常重要而您的用户将无法忍受任何早期版本时，才更新依赖项版本声明。

通过发行版分发您的依赖项，并且可以:

除了原始代码的主要/语义版本号以外，还要使用内部版本号，例如1.3.4-b3。如果我没记错的话，通常是使用专有Windows软件完成的。

当依赖项发生更改时，递增主/语义版本号，并明确显示依赖项要求。

关于此问题的更多一般性思考

我认为核心问题是动态依赖项声明– 10.0.+版本声明。您使用此声明声明的意思是您的发行版可以与任何10.0.x版本同样良好地工作。

如果确实是这样，即可以保证依赖项中的补丁所修复的错误绝不会影响发行版，那么您的发行版可能根本就不会被重建，因为其功能始终不会改变。依赖性的版本无关紧要，您的发行版可以保留较旧的依赖性版本。

不过，上游错误修复更有可能在下游项目中有所作为，即，它们将影响发行版的功能。在这种情况下，您应该在build.gradle中明确显示"new"依赖项。由于这是您的发布 Artifact 的更改，因此需要一个新的发行版本。