Question

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

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

想象一下，我已经编写了一个库，该库的公共头包含一个名为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 Program Library HOWTO-§3.6。不兼容的库：

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



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



导出的数据项更改（例外：可以在结构的末尾添加可选项，只要这些结构仅在库中分配即可。）


已删除导出的功能。



导出的函数的界面已更改。

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

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

语义版本控制：重大更改？

1 个答案: