Lt so version

[radarsat1]

This is on top of PR #58 , but I made it a separate PR because it might need discussion. I noticed when compiling that the version appended to the .so was incorrect. Importantly, in other projects, this 3-digit number is not the release number of the software, but rather is a compatibility indicator. The rules of thumb for updating the number can be seen in the changes to configure.ac. I left it at 1.0.0 because i wasn't sure what it should be for RtMidi. I propose adding this to RtMidi as a way of tracking forwards- and backwards API compatibility, but the PR should be fixed to have an appropriate number as compared to previous releases.

[garyscavone]

Is this going to cause any backward compatibility problems for users?

[radarsat1]

Just compiled the librtmidi-2.1.0 release and it produces a binary librtmidi.so.2.1.0, with symlinks librtmidi.so.2 and librtmidi.so. Programs would normally link to librtmidi.so.2. The idea is that the first number is only incremented for ABI-incompatible changes. So, when adding functions/classes, you might mark it librtmidi.so.2.2.0, or simply fixing a bug would be librtmidi.so.2.1.1. In both cases, programs would still successfully find the new versions of the library, because of the librtmidi.so.2 symlink. However, if you change a function name for example, then bump the number to librtmidi.so.3.0.0. In that case, old programs may find librtmidi.so.2, but new programs using the new function name will link against librtmidi.so.3.

Anyways, to make a "clean start," I propose setting lt_current to 3, and lt_age and lt_revision to 0, producing librtmidi.so.3.0.0. Then, following the rules for incrementing these numbers should be good for the future. (Note: Debian loves this.)

Just for reference:

Debian packaging guide: https://www.netfort.gr.jp/~dancer/column/libpkg-guide/libpkg-guide.html#sonameapiabi

Libtool manual: https://www.gnu.org/software/libtool/manual/html_node/Libtool-versioning.html