语义版本控制：主要还是较小的更改？

Question

在语义版本控制中，一般规则是仅在引入向后兼容功能时才增加次要编号，否则必须增加主要编号。将同样的方法，但使用不同的算法，是由使用的libtool。

我有一个问题，关于什么被认为是向后兼容的更改，什么不可以。

假设我已经编写了一个库，并且该库的公共标头包含一个typedef名为的数据类型foo。在1.0.0版中，这typedef看起来像这样：

typedef struct foo_t {
    int x;
    int y;
} foo;

然后，我决定更改数据类型，在下一个版本中，它将看起来像这样：

typedef struct foo_t {
    int x;
    int y;
    int z;
} foo;

我仅在结构中添加了一个字段foo_t。这似乎是向后兼容的更改，但是上面的结构实际上是现在的另一种结构。我所做的并不是引入新功能，而其余所有功能都保持不变，而是我更改了已经存在的功能。

上面的数据类型通常用于与库的功能交换数据，但是用户可能已将其用于其他目的。如果用户使用1.0.0版编写了程序，而最后的更改构成了向后兼容的更改，则用户的程序也必须使用此新版本进行编译。

这个新版本如何命名为1.1.0或2.0.0？

编辑

您可以在此处阅读此讨论的进一步发展。

Answer 1

这将是一个重大的版本更改。结构布局被烘焙到最终用户程序中。添加或删除成员是一项重大更改。无论哪种方式，布局都已更改。

从Linux程序库HOWTO中引用-§3.6。不兼容的库：

当新版本的库与旧版本二进制不兼容时，需要更改soname。在C语言中，库将不再是二进制兼容的有四个基本原因：

1. 函数的行为发生了变化，因此不再符合其原始规范，

2. 导出的数据项会发生变化（例外：可以在结构的末尾添加可选项，只要这些结构仅在库中分配即可）。

3. 导出的功能将被删除。

4. 导出功能的界面发生变化。

您说：“上面的数据类型通常用于与库的功能交换数据，但是用户可能已将其用于其他目的。” 如果该结构仅在内部使用且未在公共API中公开，则可以。但听起来用户可以自己分配一个结构变量，这意味着这是一个重大变化。

您可以通过使用不透明结构来保护您的库免受这种类型的搅动。隐藏结构的内容，并让用户仅传递指针。这就是如何FILE *工作的：C标准没有定义布局，FILE而我们作为最终用户也不知道其中的内容。