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 On Wed, Aug 21, 2013 at 12:02 AM, Tom Lee <deb...@tomlee.co> wrote: > Changelog squashed. > > CCing Kenton RE: the SONAME suggestion. > > I suspect that because capnproto is relatively young the frequent SONAME > breakages might be warranted -- I'm happy to work with that for now so long > as it's not in breach of the DPM, though I agree this may be an issue for > reverse dependencies. > > Kenton, not sure how much you've had to deal with this in the past -- any > thoughts here? Relevant docs: > > http://www.debian.org/doc/debian-policy/ch-sharedlibs.html > > "The SONAME and binary package name need not, and indeed normally should > not, change if new interfaces are added but none are removed or changed, > since this will not break binaries linked against the old shared library. > Correct versioning of dependencies on the newer shared library by binaries > that use the new interfaces is handled via the symbols or shlibs system." > > This is complicated by the use of C++, which would place restrictions on > things like virtual functions being added & removed. The KDE guys have > documented some of this stuff: > > http://techbase.kde.org/Policies/Binary_Compatibility_Issues_With_C++ > > > > On Tue, Aug 20, 2013 at 6:27 AM, Vincent Bernat <ber...@debian.org> wrote: > >> ❦ 20 août 2013 10:24 CEST, Tom Lee <deb...@tomlee.co> : >> >> > Done -- 0.2.1-1 was just uploaded to mentors: >> > >> > http://mentors.debian.net/package/capnproto >> >> Please, squash the changelog into one entry. This is a matter of taste, >> but this avoids forgetting to include all the appropriate changelog >> entries into .changes. >> >> Also, I notice that for a small change, the ABI is changing. This will >> be a bit difficult for reverse-dependencies if there are frequent >> releases. Maybe the SO name should be handled differently by upstream to >> avoid unnecessary ABI version dump. >> -- >> Don't just echo the code with comments - make every comment count. >> - The Elements of Programming Style (Kernighan & Plauger) >> > > > > -- > *Tom Lee */ http://tomlee.co / @tglee <http://twitter.com/tglee> > >
