语义版本控制和拆分库，提供捆绑构建

Question

我有一个不错的、相当受欢迎的JavaScript库，它正在跟踪语义版本化。

当前库中有几个依赖库，这些库可以作为单独的下载或者作为单个捆绑下载的一部分使用。我认为有必要进一步沿着这条道路前进。我想从一个更大的库中提取更多的、更小的库。这些解压库中的每个库都可以作为单独的文件使用，也可以在捆绑构建的内部使用。

如果我沿着提取库的路径，并提供最终代码的捆绑版本，这是否需要对语义版本进行完整的版本更改？我要从1.x跳到2.x吗？

我的第一个想法是不:我不会更改任何公共API，所以我不需要更改主要版本号。但我想知道..。嗯，我正在重组很多东西，尽管捆绑版本的最终API将是相同的。

像这样的事情，斯沃尔有明确的答案吗？我需要第一点，第二点还是第三点？还是别的什么？

Answer 1

您应该增加修补程序(第三个)号。

当您没有修复bug时，您正在进行重构，即修改问题的结构而不更改其行为。您也不会更改公共API。

以下语义版本化的相关引文

如果在不更改公共API的情况下更新自己的依赖项，该怎么办？这将被认为是兼容的，因为它不影响公共API。显式依赖于与包相同的依赖项的软件应该有自己的依赖关系规范，并且作者会注意到任何冲突。确定更改是修补程序级别还是次要级别修改取决于您是否更新了依赖项以修复bug或引入新功能。对于后一种情况，我通常期望得到额外的代码，在这种情况下，这显然是一个次要的级别增量。

-

如果只引入了向后兼容的bug修复程序，则必须增加补丁版本Z(x.y.Z-x> 0)。错误修复定义为修复不正确行为的内部更改。