[GH-ISSUE #590] ABI changes #2157

New Issue

GiteaMirror · 2026-04-20T10:07:59-05:00

GiteaMirror commented

2026-04-20 10:07:59 -05:00

Originally created by @kgold2 on GitHub (Jul 10, 2020).
Original GitHub issue: https://github.com/semver/semver/issues/590

Is there any consideration of an ABI break that does not break the API? An ABI break may require a recompile but not changes to the calling source code.

For example, a C program could take a struct parameter. If a new member was added to the struct, the API doesn't break but the ABI does.

Originally created by @kgold2 on GitHub (Jul 10, 2020). Original GitHub issue: https://github.com/semver/semver/issues/590 Is there any consideration of an ABI break that does not break the API? An ABI break may require a recompile but not changes to the calling source code. For example, a C program could take a struct parameter. If a new member was added to the struct, the API doesn't break but the ABI does.

GiteaMirror added the question label 2026-04-20 10:07:59 -05:00

GiteaMirror commented

2026-04-20 10:08:01 -05:00

@steveklabnik commented on GitHub (Jul 10, 2020):

In general, SemVer is only concerned with APIs. This comes from its heritage in dynamically typed scripting languages. That being said, its notion of "API" is up to the maintainer; you as the project owner say what your API is, and if the ABI is part of that or not.

@steveklabnik commented on GitHub (Jul 10, 2020): In general, SemVer is only concerned with APIs. This comes from its heritage in dynamically typed scripting languages. That being said, its notion of "API" is up to the maintainer; you as the project owner say what your API is, and if the ABI is part of that or not.

GiteaMirror commented

2026-04-20 10:08:01 -05:00

@Tieske commented on GitHub (Jul 11, 2020):

@steveklabnik is right. The most important (and most overlooked) element in versioning is defining the scope of the version. For example are "under the hood" database schema changes part of the version, or a file system layout? or in your case the ABI.

@Tieske commented on GitHub (Jul 11, 2020): @steveklabnik is right. The most important (and most overlooked) element in versioning is defining the scope of the version. For example are "under the hood" database schema changes part of the version, or a file system layout? or in your case the ABI.

GiteaMirror commented

2026-04-20 10:08:02 -05:00

@WayneSherman commented on GitHub (Jul 16, 2023):

Regarding API and ABI changes, I agree with this post:
https://stackoverflow.com/a/34194562

Semantic versioning should consider both [source (API) and binary (ABI) changes], and follow the "most changed" one.

Breaking source compilation is an incompatible change to users of the library.

Breaking runtime execution is an incompatible change to users of the library.

If either source compatibility or binary compatibility changes, it should -- according to semantic versioning -- be a new major version.

@WayneSherman commented on GitHub (Jul 16, 2023): Regarding API and ABI changes, I agree with this post: https://stackoverflow.com/a/34194562 > Semantic versioning should consider both [source (API) and binary (ABI) changes], and follow the "most changed" one. > > - Breaking source compilation is an incompatible change to users of the library. > - Breaking runtime execution is an incompatible change to users of the library. > > If either source compatibility or binary compatibility changes, it should -- according to semantic versioning -- be a new major version.

GiteaMirror commented

2026-04-20 10:08:03 -05:00

@FStefanni commented on GitHub (Apr 18, 2026):

Hi,

this seems a quite old discussion, but I just want to add an idea I am having, to understand if it could be accepted by the SemVer community.
Basically, if we are dealing with interpreted languages, we can safely ignore ABI issues.

But what if this is not the case? For example, a proprietary/closed-source library. Or maybe a open source library, but which is also distributed pre-compiled to avoid waiting for very long compiling times of dependencies.

In this case, knowing what changed and what has been broken became quite important and distinguish between an ABI break and an API break.

Example:

ABI break of a dependency of an open source project? We can imagine a package manager which, detecting this situation, download the source code of such open source project and recompiles. Fixed.
API change or closed source project? Sorry, unrecoverable issue (needs a developer)

So my idea is:

for backward compatibility, SemVer with 3 digits is fine, and it is still fine for interpreted languages
but for compiled langs, we introduce also a 4-digits SemVer: <API break>.<ABI break>.<new feature>.<bug fix>

This makes things obvious, since just by looking at the version we know what happened. And also alleviates developers effort to maintain their code: a developer immediately knows if a dependency can be safely updated, since a recompiling is all what is needed.

What do you think of this idea?
Is this the right place to discuss/propose this idea?

Thanks,
regards

@FStefanni commented on GitHub (Apr 18, 2026): Hi, this seems a quite old discussion, but I just want to add an idea I am having, to understand if it could be accepted by the SemVer community. Basically, if we are dealing with interpreted languages, we can safely ignore ABI issues. But what if this is not the case? For example, a proprietary/closed-source library. Or maybe a open source library, but which is also distributed pre-compiled to avoid waiting for very long compiling times of dependencies. In this case, knowing what changed and what has been broken became quite important and distinguish between an ABI break and an API break. Example: - ABI break of a dependency of an open source project? We can imagine a package manager which, detecting this situation, download the source code of such open source project and recompiles. Fixed. - API change or closed source project? Sorry, unrecoverable issue (needs a developer) So my idea is: - for backward compatibility, SemVer with 3 digits is fine, and it is still fine for interpreted languages - but for compiled langs, we introduce also a 4-digits SemVer: `<API break>.<ABI break>.<new feature>.<bug fix>` This makes things obvious, since just by looking at the version we know what happened. And also alleviates developers effort to maintain their code: a developer immediately knows if a dependency can be safely updated, since a recompiling is all what is needed. What do you think of this idea? Is this the right place to discuss/propose this idea? Thanks, regards

GiteaMirror commented

2026-04-20 10:08:04 -05:00

@Tieske commented on GitHub (Apr 20, 2026):

In this case distributed binary product is a different product than the source code.

The source has it's own version. The binary product is comprised of 1) the source code, 2) the compile time settings.

If your source doesn't change, but the compiler settings do (causing a breaking change in the ABI), then you have a new major on the binary product. If you control both, you can decide on a new major of your source to keep both in-sync.

As I mentioned above; each version should come with a definition of its scope. In this case defining whether the ABI is or is not part of the version scope.

If you add info on the ABI to the spec, then what's next? compile-time settings, endianness, targetted platforms? A deep rabbit hole...

@Tieske commented on GitHub (Apr 20, 2026): In this case distributed binary product is a different product than the source code. The source has it's own version. The binary product is comprised of 1) the source code, 2) the compile time settings. If your source doesn't change, but the compiler settings do (causing a breaking change in the ABI), then you have a new major on the binary product. If you control both, you can decide on a new major of your source to keep both in-sync. As I mentioned above; each version should come with a definition of its scope. In this case defining whether the ABI is or is not part of the version scope. If you add info on the ABI to the spec, then what's next? compile-time settings, endianness, targetted platforms? A deep rabbit hole...

Sign in to join this conversation.

1 Participants

Notifications

Due Date

No due date set.

Dependencies

No dependencies set.

Reference: github-starred/semver#2157