2

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

已发布工件的版本遵循 MAJOR.MINOR.PATCH 格式。在 build.gradle 文件中声明依赖时，我们使用动态版本，例如 10.0.+（即取最新的 10.0.PATCH 版本）。

我们将我们的工件从候选发布存储库提升到 Nexus 中的发布存储库。存储库的策略设置为“发布”。由于产品的复杂性（200 多个项目，具有许多上游和下游依赖项），Jenkins 可用的许多推广插件似乎都达不到要求。我们正在考虑让 Jenkins 构建主分支作为重命名工件（10.0.0-rc.1-abcdefg 变为 10.0.0）并将它们上传到正确的 Nexus 存储库的一种方式。

我不确定如何处理上游依赖项的补丁版本增加的情况。下游项目 - 一个 WAR - 由 Jenkins 重新构建并捆绑新的 JAR，但下游项目的版本不会改变。当尝试上传到 Nexus 时，它会失败，因为只有一个工件可以具有相同的版本。

这是一个例子：

  • Releases Nexus 存储库的上游 API 版本为 10.0.0，下游项目版本为 10.0.0
  • 下游项目依赖于 10.0.+ 的上游 API
  • upstream-api.jar 被捆绑到了下游项目.war 文件中
  • 这两个工件被部署为产品版本 X 的一部分
  • 当一个 hotfix 分支合并到 master 时，upstream-api 版本已更改为 10.0.1
  • 该修复意味着在部署时，产品现在是 Release X'
  • 下游项目保持在10.0.0，但是由于上游依赖的变化而重新构建
  • Jenkins 无法将下游项目 10.0.0.war 上传到 Nexus，因为它已经存在

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

这通常是如何处理的？

4

1 回答 1

0

这通常是如何处理的？

我在这里没有一个普遍的答案。我会假设这些是最“常见”的可能性：

  • 不要将您的依赖项与发布一起分发，并继续使用依赖项版本声明，例如10.0.+. 然后假设该软件确实可以与任何10.0.x 版本一起使用 - 至少在您的用户能够容忍的范围内。这通常发生在以源代码或 Linux 分发包系统分发的自由软件上。依赖版本声明仅在依赖需要改进时更新，即，当更改非常重要以至于您的用户不会容忍任何早期版本时。

  • 随版本分发您的依赖项，或者：

    • 除了原始代码的主/语义版本号之外，还使用内部版本号——例如 1.3.4-b3。如果我没记错的话，这通常是针对专有 Windows 软件进行的。
    • 当依赖项更改时增加主/语义版本号并使依赖项要求显式。

关于这个问题的一些更一般的想法

我认为核心问题是动态依赖声明——10.0.+版本声明。您在此声明中声明的是，您的版本将同样适用于任何10.0.x 版本。

  • 如果情况确实如此，即依赖项中的补丁修复的错误保证永远不会影响发布，那么您的发布可能根本不应该重建，因为它的功能无论如何都不会改变。依赖项的版本无关紧要，您的版本可以保留旧的依赖项版本。

  • 更有可能的是，上游的错误修正也会对你的下游项目产生影响，也就是说，它们会影响发布的功能。在这种情况下，你应该在你的build.gradle. 由于这是对您的发布工件的更改，因此需要一个新的发布版本。

于 2015-07-01T19:57:03.123 回答