Semantic versioning: minor or major change? (second part)

问题

Some time ago I had asked whether adding fields to a struct of a shared library would require a major or a minor change in the version string according to semantic versioning. The few participants where inclined to suggest a major change.

Months have passed and I have not added any fields to my struct yet. But now it might be the right time for doing it.

However in the meanwhile I have also been thinking about how this could break binary compatibility with programs compiled with previous versions of my library, and honestly, for as much as I have thought, I have not found any possible scenario where binary compatibility breaks.

The new fields are added to the end of the structure, and who uses my library normally does not allocate this struct him-/herself, but receives a pointer to it as an argument of a callback function. This is all my library does with it, the user never needs to call the library back using this struct.

The possible scenarios are two when an old program runs with the new version of the library:

1. Under normal circumstances (i.e., the old program receives a pointer to this struct and reads the fields it needs), my library will send from now on a pointer to a bigger struct, but the old program does not know it and doesn't care.
2. If the old program, for some unknown reasons, allocates this struct for its own sake, it will still allocate a smaller structure (that's what the program knew when it was compiled indeed), but my library doesn't know it and doesn't care, since it never needs to receive this struct back from the user, it only sends it as a pointer.

In the previous discussion someone had also posted this quotation from Linux Program Library HOWTO — §3.6. Incompatible Libraries:

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. The behavior of a function changes so that it no longer meets its original specification,

2. 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).

3. An exported function is removed.

4. The interface of an exported function changes.

The case no. 2 seems to talk about opaque structures. My struct is not opaque, but the situation is very similar. But the real point is that, as I said, I have not been able to find one single scenario where binary compatibility will be broken after this change.

So the question remains the same: Is this a a minor or a major version change?

回答1:

The only issue I can see is if the user does something that relies on the size of your structure and then unexpected results occur when the program is recompiled without the code being updated. Most likely to be affected would be a non-binary distribution like Gentoo or maybe a Yocto build chain.

For example, if the user were to write the contents of an array of these structures to a file that it expects to read next time the program runs. If the program gets recompiled against the new version of the library, there will be issues if it is not aware of the change between versions. Another issue may occur if bad practices like not using sizeof are present.

来源：https://stackoverflow.com/questions/58031508/semantic-versioning-minor-or-major-change-second-part