语义版本控制和依赖更改

Question

一些背景：我正在一个团队工作，该团队生产 6 个不同的 NuGet 包，它们直接、有时间接地相互依赖。简单地说，我们可能遇到像p0 < p1 < p2 这样的情况，其中包p0 依赖于p1，而p1 又依赖于p2。我们正在尝试关注Semantic Versioning 来获取这些软件包，但不太确定当p1 或p2 发生变化时如何处理p0 的版本。

下面是一些具体的例子：

• p1 进行了重大更改（例如 0.0.0 → 1.0.0）。我们想要发布一个依赖于1.0.0 的p0 版本。这应该是p0 的主要版本还是次要版本？
• p1 做了一个小改动 (0.0.0 → 0.1.0)。这是否应该为p0 带来次要版本/补丁版本？

更重要的是，

对于依赖版本更改应如何影响包版本更改是否有任何标准/共识？

Answer 1

绝不暗示@BradleyDotNET 的出色答案是不够的。我只是想补充一下我对此的看法。

p1 进行了重大更改（例如 0.0.0 → 1.0.0）。我们想发布一个依赖于 1.0.0 的 p0 版本。这应该是 p0 的主要版本还是次要版本？

是的，您正在向 p0 的用户引入一项重大更改。

p1 做了一个小的改动（0.0.0 → 0.1.0）。这是否应该为 p0 带来次要/补丁版本的提升？

如果 p1 的附加接口暴露在 p0 接口中，则为次要。如果依赖关系在实现层，则打补丁。这里真正的问题是你为什么要改变这种依赖关系？如果是给 p0 公共表面添加一个接口，那么它是 p0 的一个小凹凸，否则它是一个补丁级别的凹凸。

这里要考虑的另一件事是您将应用版本号的确切内容。包、库和接口都是不同的东西，它们都可以是独立的版本。正如 BradleyDotNET 指出的那样，一些包包含独立版本化工件的集合。尽管经常重新打包，您可能需要考虑修改您的策略，以便您的接口可以有稳定的版本。

Answer 2

语义版本控制是关于更改对库的用户意味着什么。因此，如果p1 中的更改不会导致p0 中的重大更改，那么我不明白为什么它需要p0 中的主要版本更新。

基本上，使用任何版本的依赖库（请记住，您的用户也可以根据您的依赖规则使用不同的版本覆盖它们！），您的版本控制应该只反映会影响您的用户的内容。

前面的警告、基于意见的内容

在我看来，如果您直接使用传递依赖项（即，使用p1，但仅将p0 作为依赖项列出）作为库的客户端，则存在相当多的“警告购买者”。当你有很多很多层的依赖项（就像在大多数 NPM 包中一样）时，这会增加一倍。我不希望这些库的作者跟踪所有传递依赖项的所有版本更改，所以我知道要检查。