主要的 SemVer 更新应该级联吗？
Posted
技术标签:
【中文标题】主要的 SemVer 更新应该级联吗？【英文标题】：Should major SemVer updates cascade? 【发布时间】：2014-05-30 13:01:15 【问题描述】：所以“myLibrary”引用了“anotherLibrary”。两个库都关注http://semver.org/
如果我发布了 myLibrary 的新版本，强制消费者更新到 anotherLibrary 的新主要版本，myLibrary 的主要版本是否也应该增加？
【问题讨论】：
【参考方案1】：这在 semver 的 FAQ 部分有专门回答，建议不要升级主版本。 http://semver.org/#what-should-i-do-if-i-update-my-own-dependencies-without-changing-the-public-api
【讨论】：
【参考方案2】：除非该库完全嵌入您的库中，否则是的。
假设两个库都在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。即使你的库没有暴露任何具有依赖库类型的符号，你也破坏了用户的依赖管理。
【讨论】：
通过这种方式查看它实际上使依赖项 (other) 成为 API 的一部分。我认为这有时是合法的，但并不完全是 semver 的意义所在。我正在努力解决这个问题。
@MichaelLemke 这是真的，这取决于依赖管理器的能力。如果您的语言的依赖项管理器支持私有嵌入式库，那很好（只要您这样做），但如果它需要每个库的一个且只有一个版本，或者如果您从依赖项中提供类型，那么依赖项是“一部分你的 API”。
我是从 maven 的角度来看的。【参考方案3】：
这真的取决于主库的公共 API 是否发生变化。我倾向于将图书馆视为一个黑匣子。我不需要知道它是如何实现的细节。因此，除非内部库以某种方式暴露出来，否则外部库的 API 不会改变。
所以，如果内部库根本没有公开，我会修改补丁号，仅此而已。如果内部库被公开，那么您必须确定该公开是否已发生足够的变化以保证主要版本的提升（不兼容或破坏性更改）。
当然，如果外部库的 API 已更改以支持内部库的升级，那么大版本升级是必要的。
没有外部 API 更改 - 更新补丁号 外部 API 公开内部库类型 - 更新次要或主要版本 外部 API 已更改 - 根据更改级别更新次要或主要更新【讨论】：
以上是关于主要的 SemVer 更新应该级联吗？的主要内容，如果未能解决你的问题，请参考以下文章
更新依赖项是不是会破坏向后兼容性（semver 主要版本更改）？
语义版本控制 (Semver) - 如何对向后兼容的大型功能更新进行 semver