For ELF targets, currently only one qualified SONAME is installed libpvxs.so.0.1. This doesn't capture the third (maintenance) version of a build. So far I've been able to avoid removing/changing symbols, so code linked against older libpvxs can run against a newer release. But I have added some, so this scheme doesn't fail well if the opposite happens, newer code against older libpvxs.
I've wondering if a better way to handle this is to include the full version in the SONAME, and also create additional symlinks for older compatible releases?
eg. if I had done this so far, then a future 0.1.4 release would install
For ELF targets, currently only one qualified SONAME is installed
libpvxs.so.0.1
. This doesn't capture the third (maintenance) version of a build. So far I've been able to avoid removing/changing symbols, so code linked against older libpvxs can run against a newer release. But I have added some, so this scheme doesn't fail well if the opposite happens, newer code against older libpvxs.I've wondering if a better way to handle this is to include the full version in the SONAME, and also create additional symlinks for older compatible releases?
eg. if I had done this so far, then a future 0.1.4 release would install
(I think in Mach-O land this would be expressed as
-current_version 0.1.4 -compatibility_version 0.1.0
)This PR an attempt to add some RULES to do this. eg. the preceding would be the result of:
@anjohnson Any thoughts on the ideas or method?