语义版本控制 (Semver) - 如何 semver 向后兼容的大型功能更新

Question

我的理解是，使用 X.Y.Z，我们只更改 X 来进行重大更改。 Y 表示向后兼容的功能更改。

那么，即使我的更新是对功能的绝对巨大补充——没有重大更改，因为它只是一个补充，我的假设是否正确，我仍然不会更改 X？

TLDR 无论更新有多么“重大”，如果不是重大更改，您就不会更改 X.Y.Z 的 X 吗？

Answer 1

您可以增加主要版本号以实现向后兼容的大型功能更新。我认为你通常应该这样做。

Semver 2.0.0第 8 段指出：

如果公共 API 中引入了任何向后不兼容的更改，则主版本 X (X.y.z | X > 0) 必须递增。

它可能包括次要版本和补丁级别更改。当主要版本增加时，补丁和次要版本必须重置为 0。 （强调已添加。）

严格应用

RFC 2119 术语“可以”、“必须”和“不得”（在 Semver 中通过引用并入）强调的声明意味着，当更改仅包含次要版本和补丁级别发生变化。

这就是大量的非重大更改：大量的次要更改和补丁级别更改。

规范的本段中明显缺少任何相当于以下内容的陈述：

它不能只包含较小的和补丁级别的更改
它必须包含向后不兼容的更改

根据第 7 段，另一个允许的替代方案是仅在您的场景中增加次要版本。

这很好。 它允许在您所描述的情况下进行一定的自由裁量权，其中公共 API 在技术上没有以向后不兼容的方式进行更改，但更改足够大，以至于对（可能是人类）用户来说它会“感觉”像是一个重大的侵入性更改，并且/或开发人员。

它还允许有时业务/营销驱动的需求根据重要功能更改而不是 API 规范本身来增加主要版本号。