语义版本控制：小改动还是大改动？

Question

在semantic versioning 中，一般规则是仅在引入向后兼容的功能时才增加次要编号，否则必须增加主要编号。 libtool 使用same approach，但算法不同。

我有一个问题，关于什么被认为是向后兼容的变化，什么不是。

假设我编写了一个库，该库的公共头文件包含一个名为foo 的数据类型的typedef。在 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 添加了一个字段。这似乎是一个向后兼容的变化，但是上面的结构现在是 de facto 另一个结构。我所做的不是引入一个新功能，其余的都保持不变，而是我改变了一些已经存在的东西。

上述数据类型通常用于与库函数交换数据，但用户可能将其用于其他目的。如果用户使用 1.0.0 版本编写了程序，并且最后一次更改构成向后兼容的更改，则用户的程序也必须使用这个新版本进行编译。

这个新版本怎么叫，1.1.0还是2.0.0？

编辑

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

Answer 1

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

引用Linux Program Library HOWTO — §3.6。不兼容的库：

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

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

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

   李>

3. 导出的函数被移除。

4. 导出函数的接口发生变化。

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

您可以使用opaque structs 保护您的图书馆免受此类流失的影响。隐藏结构的内容，让用户只传递指针。这正是 FILE * 的工作原理：C 标准没有定义 FILE 的布局，我们作为最终用户不知道其中的内容。