This is an old, old debate that goes back to when shared libraries were first developed. Your examples are fine, but consider the common case of wanting to take advantage of the bugs fixed in 0.12.3. Users of 0.12.2 need to rebuild all software that depends on libraw. For many users, this is unacceptable.
One common way to deal with the API/ABI problem is to say that the API won't change for a given release number, say, 0.12. In 0.13, the API might change (or it might not). Software writers can deal with this as they like.
I would encourage you to examine how other open-source projects deal with this problem. Almost all open-source libraries out there with unstable APIs release their software as shared libraries.
Some people would say there is no such thing as a stable API; even mature libraries, like GTK, are still undergoing revision.
Finally, note that packaging libraw into a .so does *not* force everyone to use it as such. Application writers may statically link in the .o's if they want.
This is an old, old debate that goes back to when shared libraries were first developed. Your examples are fine, but consider the common case of wanting to take advantage of the bugs fixed in 0.12.3. Users of 0.12.2 need to rebuild all software that depends on libraw. For many users, this is unacceptable.
One common way to deal with the API/ABI problem is to say that the API won't change for a given release number, say, 0.12. In 0.13, the API might change (or it might not). Software writers can deal with this as they like.
I would encourage you to examine how other open-source projects deal with this problem. Almost all open-source libraries out there with unstable APIs release their software as shared libraries.
Some people would say there is no such thing as a stable API; even mature libraries, like GTK, are still undergoing revision.
Finally, note that packaging libraw into a .so does *not* force everyone to use it as such. Application writers may statically link in the .o's if they want.