语义版本控制:小改动还是大改动? [英] Semantic versioning: minor or major change?

问题描述

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

In semantic versioning the general rule is to increase the minor number only when backwards compatible functionalities are introduced, otherwise the major number must be increased instead. The same approach, but with a different arithmetic, is used by libtool.

我有一个问题，什么被认为是向后兼容的更改，什么不是.

I have a question concerning what is considered a backwards compatible change and what not.

假设我写了一个库，这个库的公共头文件包含一个名为 foo 的数据类型的 typedef.在 1.0.0 版本中，这个 typedef 看起来像这样:

Imagine I have written a library, and the public header of this library contains a typedef of a data type named foo. In version 1.0.0 this typedef looks like this:

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

然后我决定改变数据类型，在下一个版本中它会是这样的:

Then I decide to change the data type, and in the next version it will look like this:

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

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

I have only added one field to the structure foo_t. It would seem to be a backward compatible change, however the structure above is de facto another structure now. What I have done was not introducing a new function and leave untouched all the rest, but instead I have changed something that was already there.

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

The data type above is normally used for exchanging data with the library's functions, however the user might have used it with other purposes. If the user had written a program using version 1.0.0 and the last change constitutes a backward compatible change, the user's program must compile also with this new version.

这个新版本将如何命名，1.1.0 还是 2.0.0?

How will this new version be called, 1.1.0 or 2.0.0?

编辑

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

You can read further developments of this discussion here.

推荐答案

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

It would be a major version change. Struct layouts are baked into end user programs. It is a breaking change to add or remove members; either way, the layout has changed.

引自 Linux 程序库 HOWTO — §3.6.不兼容的库:

Quoting from the Linux Program Library HOWTO — §3.6. Incompatible Libraries:

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

When a new version of a library is binary-incompatible with the old one the soname needs to change. In C, there are four basic reasons that a library would cease to be binary compatible:

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

1. The behavior of a function changes so that it no longer meets its original specification,

导出的数据项发生变化(例外:在结构的末尾添加可选项是可以的，只要这些结构仅在库内分配).

Exported data items change (exception: adding optional items to the ends of structures is okay, as long as those structures are only allocated within the library).

删除了导出的函数.

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

The interface of an exported function changes.

您说，上述数据类型通常用于与库函数交换数据，但用户可能将其用于其他目的."如果该结构仅在内部使用而不在公共 API 中公开，那您就可以了.但听起来用户可以自己分配一个结构体变量，这意味着这是一个突破性的变化.

You say, "The data type above is normally used for exchanging data with the library's functions, however the user might have used it with other purposes." If the struct were used internally only and not exposed in the public API you'd be okay. But it sounds like the user could allocate a struct variable themselves, which means it's a breaking change.

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

You can protect your library from this type of churn by using opaque structs. Hide the contents of the structs and have the user just pass around pointers. This is exactly how FILE * works: the C standard doesn't define the layout of FILE and we as end users don't know what's inside of it.

这篇关于语义版本控制:小改动还是大改动?的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！