内部Java依赖关系的Maven依赖关系版本控制

内部开发依赖项的版本控制

我正在寻找其他团队如何在他们的项目中涵盖这一点的一些示例/最佳实践。
我有一个中等规模的开发团队，他们正在使用Maven作为构建工具开发Java应用程序。
我们内部开发了许多依赖项，供一个或多个其他应用程序使用;都使用CI工具来做运行测试和构建等所有好的事情。
我的问题是关于应用程序POM文件中内部依赖项的版本控制的最佳实践。
我的直觉是，CI应该构建依赖关系，并在变更合并到git repo的主分支和包的semver时标记git repo，如果开发人员和他们的应用程序需要该版本，那么POM文件应该更新，并使用CI构建包含该版本的应用程序。
这当然会增加更大的开销，而不是每次构建应用程序时都使用最新版本的依赖项，但至少您准确地针对每个应用程序所需的内容;尽管它们都可能运行不同版本的依赖性。
除了推出安全更新，这可能不是太不可取？
我担心的是，如果两个开发者在同一个应用程序上独立开发一个特性和一个依赖项，那么就有可能引入版本回归。虽然我想这会在git中被视为冲突，或者至少应该被视为一个可见的变更，并且开发者有责任检查他们正在合并的版本是否比主分支中的当前版本更老。
我想我只是在一些其他人正在做的多个开发人员同时更改应用程序和他们的开发人员的指针。
通常是在别人正在做的一些例子之后。

总的来说，你所问/谈论的听起来很明显，没有什么可讨论的。我的两点意见：

很有可能，将拉取请求集成到分支中发布新版本的想法行不通，原因如下：

为了发布新版本，您需要更改pom.xml中元素的值<version>，maven-release-plugin在两次提交中执行此操作：第一个将-SNAPSHOT（当前开发版本）更改为“release”，第二个将“release”更改为-SNAPSHOT（下一个开发版本），maven-release-plugin的这种行为是合理的，但您可能会面临以下“问题”：

来自maven-release-plugin的提交历史记录中有大量噪音
maven-release-plugin将与同时集成冲突，基本上它将无法提交到陈旧分支

我们倾向于发布中间版本（pre-release/build）用于这样的情况（自动地或按需地），类似于：

mvn -e --batch-mode -Prelease release:clean release:prepare \
  -Darguments='-DaltReleaseDeploymentRepository=... -DaltSnapshotDeploymentRepository=... -DskipTests=true' \ 
  -DreleaseVersion=X.Y.Z-BUILDNO \
  -DdevelopmentVersion=X.Y.Z-SNAPSHOT \
  -DpushChanges=false \
  -DpreparationGoals="clean deploy"

1.最具挑战性的部分实际上是分支策略：假设develop/main分支中当前的开发版本是X.Y.Z-SNAPSHOT，问题是：“如果我们要发布软件的新版本，下一个开发版本是什么？”（默认情况下，maven-release-plugin建议X.Y.(Z+1)-SNAPSHOT，但在这种情况下，由于develop/main分支中的其他（可能冲突/不需要）变更，您将无法发布bugfix版本）

内部Java依赖关系的Maven依赖关系版本控制

内部开发依赖项的版本控制

1条答案

相关问题

热门标签

最新问答