[LAD] library soname, was Re: Rubber Band Library v3.0.0 released

On Fri, 15 Jul 2022, at 23:02, Robin Gareus wrote: Thank you! Yes to both... I hope. The version in the .pc file is written in at install time, although I guess it would be nice to have the right version in place in .pc.in in the first place (or to omit it until installation) as it does look kind of confusing. The ABI has been at 2.something since version 1.2, which was the last release to break binary compatibility. This release bumped it from 2.1.7 to 2.2.0. A program dynamically linked against version 1.2 will still run correctly against this new version. But I find that after all these years I am still not totally clear on whether a *compatible* change to the ABI should cause a change to the soname, or only to the minor number. I thought I knew this, but I find now that sources contradict each other, and sometimes themselves, with great confidence - and it's been such a long time that I can no longer remember exactly why I formed my own view in the first place. For example: https://tldp.org/HOWTO/Program-Library-HOWTO/shared-libraries.html section 3.1.1 "The soname has the prefix ``lib'', the name of the library, the phrase ``.so'', followed by a period and a version number that is incremented whenever the interface changes". This implies that if you e.g. add a function, you should change the soname. section 3.6 "When a new version of a library is binary-incompatible with the old one the soname needs to change... you can keep your Application Binary Interface (ABI) compatible if you avoid such changes. For example, you might want to add new functions but not delete the old ones". This implies that if you add a function, you need not change the soname. I always took the view that if the library can be upgraded without breaking an application linked against the old version, it should have the same soname (i.e. first component of ABI version) because the alternative would be too annoying in practice. That seems consistent with many other libraries, anyway. But it does mean that library downgrades don't fail cleanly and I am definitely finding sources out there that suggest it isn't the right thing to do after all. Has consensus on this changed over the years perhaps? Chris