We frequently find projects versioning their libraries incorrectly -- i.e., 
using the project's version number as the library version number. For example 
here's a library that I'm almost certain is doing it wrong:


$ port installed tidy
The following ports are currently installed:
  tidy @4.9.26_0+universal (active)

$ otool -L /opt/local/lib/libtidy.dylib
/opt/local/lib/libtidy.dylib:
        /opt/local/lib/libtidy.4.dylib (compatibility version 4.0.0, current 
version 4.9.26)
        /usr/lib/libSystem.B.dylib (compatibility version 1.0.0, current 
version 1213.0.0)


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?

_______________________________________________
macports-dev mailing list
[email protected]
https://lists.macosforge.org/mailman/listinfo/macports-dev

Reply via email to