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

时间:2019-04-12 20:47:54

标签: javascript npm semantic-versioning

我的理解是,使用X.Y.Z,我们仅更改X即可更改更改。 Y用于向后兼容的功能更改。

我是正确的,即使我的更新绝对是功能的巨大补充-没有重大更改,因为它只是一项添加,我仍然不会更改X。

TLDR 无论更新有多“重要”,如果不是重大更改,都不要更改X.Y.Z的X

1 个答案:

答案 0 :(得分:2)

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

Semver 2.0.0的第8段指出:

  

如果向公共API引入了任何向后不兼容的更改,则必须增加主版本X(X.y.z | X> 0)。 它可能包括次要版本和补丁程序级别更改。当主要版本增加时,必须将补丁程序和次要版本重置为0。 (添加了强调。)

严格遵守RFC 2119术语MAY,MUST和MUST NOT(以引用方式并入Semver),强调的语句表示允许但不要求在变更包括以下内容时增加主版本号仅次要和补丁程序级别更改。

这就是大量的不间断更改:大量的次要和补丁级别更改。

在规范的这一段中明显缺少的是等同于以下内容的任何声明:

  • 它不得仅包含次要和补丁程序级别的更改
  • 它必须包括向后不兼容的更改

基于第7段,另一个允许的选择是仅在您的方案中增加次要版本。

这很好。在您描述的情况下,公共API并没有在技术上以向后不兼容的方式进行更改,但是更改幅度很大,足以使您感觉为(大概是人类)用户和/或开发人员。

它还允许有时出于业务/市场需求,需要根据重要的功能更改而不是API规范本身来增加主要版本号。