次要版本更新可用于次要更新传递依赖项吗？

可以说我创建了我的库foo从版本1.0.0到1.0.1的二进制兼容更新。库foo通过Maven发布。次要版本更新可用于次要更新传递依赖项吗？

我可以使用这个次要版本更新来同时冲击foo的依赖关系的次要版本吗？例如，版本1.0.0使用scalaVersion := "2.10.1"。我可以在foo 1.0.1中将其更改为scalaVersion := "2.10.3"，还是会造成麻烦？

假设我用foo在另一个项目为

"mygroup" %% "foo" % "1.0.+"

来源

2014-01-30 0__

您应该管理父pom.xml中的版本号。这样更新后的版本被填充到所有子模块。那是你正在寻找的东西吗？ –

你怎么知道Scala 2.10.3不会破坏你的代码？还是一个取决于你的代码的项目？ – HDave

@ chris.tian没有父母。斯卡拉图书馆是独立于我的图书馆。 –

有涉及到几个方面的考虑，但通常是的，你可以改变依赖的版本，如果他们是二进制兼容。 Scala团队希望2.10.x版本能够兼容二进制文件。您可以在Scala 2.10.1上编译并在运行时使用2.10.3。

只要您使用两种存在的方法和类型，通常可以对Scala库做相反的处理。虽然大多数图书馆都不关心这个方向。其他有关二进制兼容性的注意事项：

不同的图书馆对什么版本的颠簸有不同的策略。
库可能有也可能没有自动检查二进制兼容性。
自动化像MiMa（由Scala使用）不能捕捉各种不兼容性。例如，MiMa只捕捉“语法”不兼容（在运行时抛出LinkageError）。
二进制兼容性并不意味着源代码兼容性。

但是，通常不建议使用动态修订版本，如“1.0。+”。它们使复制建设变得更困难，并影响分辨率速度。

来源

2014-02-09 20:12:08

我很惊讶，你建议不要使用'+'版本。我很喜欢他们。它允许我发布一个错误修复版本，任何新项目都可以自动利用它们。与我的问题有关的种类：如果我的项目的两个依赖关系A和B依赖于两个不同次要版本中的C， '1.0.0'和'1.0.1'，我想我最终在'lib_managed'中有'1.0.0'和'1.0.1'，或者会自动回退到'1.0.1'？这对我来说是使用'1.0。+'的动机。 –

关于lib_managed，请参阅http://stackoverflow.com/a/21368201。常春藤将解决两个不同的版本。 Ivy的默认策略是使用最新版本，所以1.0.1会被选为1.0.0以上。 –

在动态修订版中，它们使重复性更难。你可以做到，但它需要更多的工作，最终你不再使用动态修订。请注意，它们不是由Gradle或Maven推荐的。 –

一般现代软件如下semantic versioning

给定一个版本号MAJOR.MINOR.PATCH，递增：

MAJOR version when you make incompatible API changes, 
MINOR version when you add functionality in a backwards-compatible manner, and 
PATCH version when you make backwards-compatible bug fixes.

所以"2.10.3"是要与任何"2.10.x"版本兼容。

通常我们不应该关心.PATCH部分，除了影响我们代码的bug被修复的情况。我想这是事实。

来源

2014-02-12 05:32:39

次要版本更新可用于次要更新传递依赖项吗？

回答

相关问题