mirror of
https://github.com/semver/semver.git
synced 2026-07-10 19:50:47 -05:00
[GH-ISSUE #590] ABI changes #5541
No Assignees
Notifications
Due Date
No due date set.
Dependencies
No dependencies set.
Reference: github-starred/semver#5541
Reference in New Issue
Block a user
Delete Branch "%!s()"
Deleting a branch is permanent. Although the deleted branch may continue to exist for a short time before it actually gets removed, it CANNOT be undone in most cases. Continue?
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.
@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.
@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.
@WayneSherman commented on GitHub (Jul 16, 2023):
Regarding API and ABI changes, I agree with this post:
https://stackoverflow.com/a/34194562
@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:
So my idea is:
<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
@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...
@FStefanni commented on GitHub (Apr 21, 2026):
Hi,
thank you for sharing your opinion.
I disagree on the "rabbit hole", since no other parameter is relevant imho.
Basically what I am trying to say is that already all other stuff is covered and correctly handled by the 3-digits SemVer.
ABI changes are not: when you increase the major you are telling that developers must take action.
But if it is only an ABI change, this is false.
In case of source code distribution, as Rust for example, we can also think about creating a package manager that, in case of ABI breaking change, just happily recompiles the code, since it is the only true required action.
With current 3-digits SemVer schema, we are missing this info.
Regards
@hasufell commented on GitHub (Apr 21, 2026):
@FStefanni you are aware that you can break ABI without breaking API, yes? And you can break API without breaking ABI.
There is a relation between the two, but it is not that straightforward. That's why SONAMEs for C libraries don't always correspond to the library version (e.g. libc, libcurl).
@FStefanni commented on GitHub (Apr 22, 2026):
Hi,
thank you for your comment that points out a important aspect.
Yes I am aware that, and in particular that breaking API does not forcefully means breaking ABI.
But here I propose to give more importance to API (first digit) w.r.t. ABI (second digit), since breaking ABI just requires that the developer recompiles the code (trivially fixable), whilst fixing the API requires that the developer understands what changes happen and how to update the code (it requires some effort).
It is the same logic behind "new feature" and "bugfix": "new feature" has the minor (in the 3-digits schema) since it requires some effort by the developers to discover what has been added and how to use possibly it, whilst a "bugfix" is a no brainer.
Regards