I do have experience with sonames, actually, from protobufs. My experience was:
- We never did two releases that had the same binary interface.
- We occasionally forgot to bump the soname, leading to problems.
The nature of C++ is that binary compatibility between versions is nearly impossible to maintain, unless you design your interface in a very careful and limiting way. You want people to be able to allocate objects on the stack, but that means that if the size of the object changes, the ABI has changed. And then there's inline methods, templates, etc., all of which Cap'n Proto uses extensively. Moreover, Cap'n Proto is a library where nearly every module has a public API. If it, say, had one main public interface wrapping a large implementation, the ABI would be more manageable.
So, I set the flag on libtool to have it just use the whole version number as the soname. That way at least there's no chance of accidents leading to subtle bugs.
It happens to be true that 0.2.0 -> 0.2.1 did not change the binary interface, because no headers were modified. However, I expect this to be pretty rare.
Perhaps a strategy for reducing trouble with dependencies would be to only update dependencies to the latest Cap'n Proto release a few weeks after such a release takes place, since the chance of a subsequent point release falls off with time.
And, yeah, we're pretty early in development and I'm not even aware of anyone using Cap'n Proto in real projects yet, so for the moment dependency churn isn't a big deal. Later on, there will be more dependencies, but there will also be fewer releases.
-Kenton