ABI changes #424

New Issue

GiteaMirror · 2026-02-17T12:04:09-06:00

GiteaMirror commented

2026-02-17 12:04:09 -06:00

Originally created by @kgold2 on GitHub (Jul 10, 2020).

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). 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-02-17 12:04:09 -06:00

GiteaMirror commented

2026-02-17 12:04:10 -06: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-02-17 12:04:11 -06: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-02-17 12:04:12 -06: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 referenced this issue

2026-04-16 10:29:30 -05:00

[GH-ISSUE #424] SemVer does not use SemVer for releases #1178

GiteaMirror referenced this issue

2026-04-20 09:56:55 -05:00

[GH-ISSUE #424] SemVer does not use SemVer for releases #2045

GiteaMirror referenced this issue

2026-04-25 17:14:42 -05:00

[GH-ISSUE #424] SemVer does not use SemVer for releases #3027

GiteaMirror referenced this issue

2026-06-13 12:47:29 -05:00

[GH-ISSUE #424] SemVer does not use SemVer for releases #4556