假设我有一个可以通过类似 API 调用的函数,$MyFunction
并且为简洁起见$MyFunction
返回 12。现在假设我重命名$MyFunction
为,$The12Function
但它仍然返回相同的结果(在此示例中为整数 12)。这是否需要增加主要或次要 SemVer 版本号?
有人可能会争辩说我不允许向后兼容,因为它$MyFunction
不再有效。但是,也有人会争辩说存在向后兼容性,因为您仍然可以通过$The12Function
.
假设我有一个可以通过类似 API 调用的函数,$MyFunction
并且为简洁起见$MyFunction
返回 12。现在假设我重命名$MyFunction
为,$The12Function
但它仍然返回相同的结果(在此示例中为整数 12)。这是否需要增加主要或次要 SemVer 版本号?
有人可能会争辩说我不允许向后兼容,因为它$MyFunction
不再有效。但是,也有人会争辩说存在向后兼容性,因为您仍然可以通过$The12Function
.
给定版本号 MAJOR.MINOR.PATCH,增加:
进行不兼容的 API 更改时的主要版本,
以向后兼容的方式添加功能时的次要版本,以及
进行向后兼容的错误修复时的补丁版本。
因此,在您的情况下,如果您不维护旧函数名称,为了保持与旧版本 API 的兼容性,您应该增加主要版本号。
为了了解兼容性是否被破坏,一种看待它的方法是想象您的 API 和功能被封装在一个库中,该库向其他程序提供此功能。您现在对该 API 进行更改。如果需要更改链接到旧版本 API 的程序才能使用新版本的库,则说明兼容性已损坏,应更改主版本。您可以通过覆盖和维护已弃用的旧函数调用来解决此问题,但这会增加 API 的复杂性。