所以“myLibrary”引用“anotherLibrary”。这两个库都遵循http://semver.org/
如果我发布了 myLibrary 的新版本，强制消费者更新到 anotherLibrary 的新主要版本，myLibrary 的主要版本是否也应该增加？
问问题
1964 次
3 回答
5
这在 semver 的 FAQ 部分有专门的回答，建议不要升级主版本。http://semver.org/#what-should-i-do-if-i-update-my-own-dependencies-without-sharing-the-public-api
于 2017-10-17T18:26:02.720 回答
3
这真的取决于主库的公共 API 是否发生变化。我倾向于将图书馆视为一个黑匣子。我不需要知道它是如何实现的细节。因此，除非内部库以某种方式暴露出来，否则外部库的 API 并没有改变。
所以，如果内部库根本没有公开，我会修改补丁号，仅此而已。如果内部库被公开，那么您必须确定该公开是否已发生足够的变化以保证主要版本的提升（不兼容或破坏性更改）。
当然，如果外部库的 API 已更改以支持内部库的升级，那么大版本升级是有保证的。
- 没有外部 API 更改- 更新补丁号
- 外部 API 公开内部库类型- 更新次要或主要版本
- 外部 API 已更改- 根据更改级别更新次要或主要
于 2014-04-16T08:09:15.280 回答
1
除非该库完全嵌入您的库中，否则是的。
假设两个库都在1.0. 用户可以声明他们的依赖项，例如：
other ~> 1.0
yours ~> 1.0
Where~>表示对任何与 兼容的版本的依赖1.0，即1.x.y.
您的图书馆声明：
other ~> 1.0
所以一切正常，依赖关系可以解决。如果other移动到1.1.0，一切仍然有效。
现在，您的库切换到：
other ~> 2.0
...并将其发布为 version 1.1.0。这与用户声明的依赖项不兼容。他们想要一个1.x版本other和一个1.x版本yours，以前可以，但现在不行。因此，您必须将其发布为 version 2.0。即使您的库没有公开任何具有依赖库类型的符号，您也破坏了用户的依赖管理。
于 2015-12-11T20:37:28.790 回答