preparing new RtMidi release, question about SO version

[IOhannes m zmölnig (Debian/GNU)]

On 02/10/2016 06:21 PM, Stephen Sinclair wrote:
> Previous versions have made the error of treating SO version like the
> version number, and producing binaries e.g. librtmidi.so.2.1.0.
> 
> I was recommending changing this to properly reflect ABI
> compatibility.  What would Debian maintainers prefer here?
> 
> I proposed making the new SO version 3.0.0, to really emphasize that
> the ABI version is new, however since it's a bugfix release I don't
> know if that's the recommended strategy.

the question is: *is* the ABI new? has it changed?
just because you decided to switch to semantic versioning doesn't
necessarily change the ABI.

i would suggest to not do a soname bump for anything *but* ABI changes.

there's a good overview about when you should (not) bump which of the
various numbers on [http://semver.org/]

> 
> https://github.com/thestk/rtmidi/pull/59
> 
> In any case I notice that the interface has changed a bit, e.g. some
> functions have lost parameters, others have new parameters, since the
> last release.

otoh, if functions *have* changed you are breaking the ABI.

if this was a C-library, then adding/removing function parameters would
not change the exported symbols, so any application built with the
previous version the lib would still successfully "load" when run-time
linked against the new version.
however, since the function semantics have changed, you would get
spurious and hard to debug crashes. (warranting a soname bump to prevent
old application accidentally using the new library).

since this is a C++-library, changing the function arguments will
effectively change the exported symbol names;
therefore an application built with the old library will simply fail to
load (since the symbols won't resolve).
this is great as it explicitely tells you that you need a soname bump.

there are a few Debian packages that can help you tracking ABI changes.


gfmsdr
IOhannes





-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 819 bytes
Desc: OpenPGP digital signature
URL: <http://lists.alioth.debian.org/pipermail/pkg-multimedia-maintainers/attachments/20160211/8f700001/attachment.sig>