Proper library version numbering

Arto Bendiken arto at
Sat May 2 11:22:30 PDT 2015

On Sat, May 2, 2015 at 3:30 PM, Lawrence Velázquez <larryv at> wrote:
> On May 2, 2015, at 9:05 AM, Ryan Schmidt <ryandesign at> wrote:
>> But it's not totally clear to me what proper library versioning entails -- what specifically I should be telling the developers of those projects to do instead. There are too many different version numbers. For example:
>> $ port installed gettext
>> The following ports are currently installed:
>>  gettext @0.19.4_0+universal (active)
>> $ otool -L /opt/local/lib/libintl.dylib
>> /opt/local/lib/libintl.dylib:
>>       /opt/local/lib/libintl.8.dylib (compatibility version 10.0.0, current version 10.3.0)
>>       /opt/local/lib/libiconv.2.dylib (compatibility version 8.0.0, current version 8.1.0)
>>       /usr/lib/libSystem.B.dylib (compatibility version 1.0.0, current version 1213.0.0)
>>       /System/Library/Frameworks/CoreFoundation.framework/Versions/A/CoreFoundation (compatibility version 150.0.0, current version 1151.16.0)
>> Assuming gettext is an example of proper library version numbering, what's the relationship between version "0.19.4" and version "8" and version "10.3.0"? What do each of those numbers represent? What would be the appropriate circumstances when a developer would change each of those numbers?

In addition to the link from Larry, Apple's developer tutorial for
creating dynamic libraries is helpful as well, explaining through a
concrete case example how the version information changes as the
library API/ABI is changed:

Further, having packaged for both MacPorts and Fink, the latter are
rather more strict about this ABI versioning business. It may be
helpful to read their shared library packaging policy:

Arto Bendiken | @bendiken |

More information about the macports-dev mailing list