所以“myLibrary”引用“anotherLibrary”。两个图书馆都遵循http://semver.org/
如果我发布了myLibrary的新版本，迫使消费者更新到另一个图书馆的新主要版本，那么myLibrary的主要版本是否会增加？
答案 0 :(得分：3)
这实际上取决于主库的公共API是否发生了变化。我倾向于将图书馆视为黑匣子。我不需要知道它是如何实现的细节。因此，除非以某种方式暴露内部库，否则外部库的API没有改变。
所以，如果根本没有公开内部库，我会碰到补丁编号，就是这样。如果内部库已暴露，那么您将必须确定该曝光是否已经发生了足够的变化以保证主要版本的冲突（不兼容或不断变化）。
当然，如果外部库的API已更改为支持内部库的升级，则需要保证主要版本的冲击。
答案 1 :(得分：2)
这在semver的FAQ部分中得到了具体解答，建议主要版本不会被提升。 http://semver.org/#what-should-i-do-if-i-update-my-own-dependencies-without-changing-the-public-api
答案 2 :(得分：0)
除非图书馆完全嵌入你的图书馆，否则。
假设两个库都在1.0上。用户可以声明他们的依赖关系，如：
other ~> 1.0
yours ~> 1.0
~>表示依赖于与1.0兼容的任何版本，即1.x.y。
你的图书馆声明：
other ~> 1.0
所以一切正常，依赖关系可以解决。如果other移至1.1.0，则一切仍然有效。
现在，你的图书馆切换到：
other ~> 2.0
...并将其作为版本1.1.0发布。这与用户声明的依赖项不兼容。他们需要1.x版本的other版本和1.x版本的yours版本，之前有效，但现在却没有。因此，您必须将其作为版本2.0发布。即使您的库没有从依赖库中公开任何带有类型的符号，您也已经破坏了用户的依赖关系管理。