试图向朋友解释语义版本控制的重要性，我面临着以下困境。
假设我们有库libfoo，版本1.2.3，它公开了以下函数：
def foo(x, y):
"""
Compute the sum of the operands.
:param x: The first argument.
:param y: The second argument.
:returns: The sum of `x` and `y`.
"""
return x + y
现在假设此函数及其文档更改为：
def foo(a, b):
"""
Compute the sum of the operands.
:param a: The first argument.
:param b: The second argument.
:returns: The sum of `a` and `b`.
"""
return a + b
我的第一印象是说下一个版本将是1.2.4，因为公共界面没有改变。例如，像这样调用函数的人根本不会注意到更改：
foo(3, 4)
但进一步思考，这很可能是一个 API 中断，因为 Python 允许人们通过名称指定参数。如果有人像这样调用我的函数：
foo(y=4, x=3)
这在版本1.2.4中不再起作用，破坏了语义版本控制契约。
另一方面，这样的变化似乎很小，以至于我会对将版本增加到2.0.0感到难过。
总而言之，这是否构成 API 中断？在这种情况下，下一个版本号应该是什么？
简短回答：是的，我认为这将构成 API 中断，从而可能会增加主要版本号。不过，请注意下面的注意事项。
<小时 />当您公开公共/外部 API 时，您需要承担额外的"注意义务"来仔细考虑对接口的更改。例如，这包括推迟潜在的改进以避免破坏向后兼容性*。在维护 API 时，应非常仔细地考虑任何会合法影响使用接口的任何代码**的更改。
语义版本控制的规范是明确的：
主要版本 X （X.y.z |X> 0） 如果向公共 API 引入了任何向后不兼容的更改，则必须递增。
正如您在问题中指出的那样，更改参数的名称会引入按关键字传递参数的代码向后不兼容。
但是，与其说此更改应该增加主要版本，不如说不应该进行更改，或者至少不应该孤立地进行更改 - 这是一个太小的更改，无法证明可能破坏现有有效代码所需的主要增量是合理的。除以下情况之一外：
- 它是一些更大的重要变化的一部分;或者
- 您的示例中未显示的更改有一个很好的理由（一些显示停止的错误，或依赖于它的其他功能）;
我会完全推迟更改。最好放慢速度，确保继续满足语义版本控制契约，只有在有令人信服的理由的情况下才能进行此类更改。
<小时 />从 Python 3.8 中，您可以指定仅位置参数，在 PEP 中指出了此类问题作为理由的一部分（强调我的）：
如果 API 的调用方开始使用关键字参数，则库作者无法重命名参数，因为它将是一个中断改变。
在这种情况下，如果原始定义是：
def foo(x, y, /):
那么重命名参数将不是重大更改。
<小时 />* 当我们在 Python 标签中时，请考虑整数除法，尽管被 BDFL 承认为错误，但直到今天仍在 2.x 版本中。
** 我说"合法"是为了排除未将其用作官方文档的代码，例如通过访问私有约定属性 - 他们应该期望偶尔会感到不便！因此，如果您预测了此更改，并且明确指定仅应使用位置参数，则此更改是可以的，但这将是一个奇怪的选择。
这种类型的更改可能属于发布规模的许多不同的领域。
主要变化（从 1.x 递增到 2.x）
这会破坏您的 API 合同，并符合重大更改的条件。不过，需要注意的是，这是否是唯一的变化。如果是，我不会将其作为主要版本更改。另一方面，如果这是也会破坏您的 API 合同的众多更改之一，我相信主要版本增量是合理的。
微小变化（从 1.2 增加到 1.3）
借用 Python 文档：
次要版本号[被]递增，以减少惊天动地的更改。
对我来说，这是一个很小的变化。正如您所说，如果用户没有命名他们的参数，他们甚至不会注意到发生了更改。
微变化（从 1.2.3 增加到 1.2.4）
这是您的错误修复更改级别。如果您因为 bug 而将foo(x, y)更改为 foo(a, b)，则此修复程序证明微点增量是合理的。
我对这种变化的看法是使其成为一个小的变化。这当然不是一个"惊天动地"的更改，但它确实可能会迫使最终用户更改代码。我不会将其归类为重大更改，因为它仅在函数调用上更改参数名称，否则该函数调用的行为方式完全相同，返回完全相同的数据，并将完全相同的数据作为参数，但只是将它们应用于函数中的不同名称。