glibc has really good backward compatibility. But, yeah, few other libraries even bother, let alone make a serious attempt at this. One of the major exceptions

glibc has really good backward compatibility. But, yeah, few other libraries even bother, let alone make a serious attempt at this. One of the major exceptions is libvirt, which promised 100% backward compatibility from day 1. Here's a great overview (2011) of how they accomplish that: https://www.berrange.com/posts/2011/01/13/versioning-in-the-libvirt-library/ https://www.berrange.com/posts/2011/01/13/versioning-in-the-... Note that it wasn't until GCC 10 (2020) that you could implement ELF symbol versioning without using an ugly inline asm hack in your function definition. From the GCC 10 release notes at https://gcc.gnu.org/gcc-10/changes.html https://gcc.gnu.org/gcc-10/changes.html: > The symver attribute can be used to bind symbols to specific version nodes on ELF platforms. This is preferred to using inline assembly with GNU as symver directive because the latter is not compatible with link-time optimizations. In combination with confusion around the differences between file suffix versioning, soname versioning, and symbol versioning, it's not surprising few developers even attempt to get this right. OTOH, most ABI breakages are because of dumb mistakes early on or gratuitous changes to the API. If you commit to API stability from the beginning, then ABI stability can and will come more naturally, at least for C code. Versioning of any sort becomes less complicated and even less important.[1] C++ is different because of how heavily header-defined templates are used these days. [1] In other words, if you think API and ABI stability is principally a question of versioning, such as semantic versioning, you're doing it wrong. Commit to 100% backward compatibility at the API level and the answers to most of your design dilemmas become obvious. With the reduced cognitive burden, minding ABI compatibility becomes easier.