I think it is a bit unfortunate that we don't have a system to determine whether boost updates break existing api's. The usual process is that, for example, suppose we have
libboost.so.1.33.0
Let's assign this soname libboost.so.1. Then a symlink is created
libboost.so.1 -> libboost.so.1.33.0.
Symlink is generated via ldconfig on linux, other dynamic loader machinery on other systems. You can't simply do this link randomly and expect it to work: it's generated from the way the shared object is constructed. (Not the way it's named, at least not on all systems.)
Now if a bugfix comes out that does not change the api, be can have
ABI, not API.
libboost.so.1.33.1, which also has soname libboost.so.1, and then symlink:
libboost.so.1 -> libboost.so.1.33.1
...the rest is largely correct for linux in particular. The boost build/configure machinery can be made to work with linux conventions. Thanks Rene! However, boost in the past has not made this kind of interim release. I realize, after catching up on this list, that they may or may not do something like 1.33.1 in the future. This kind of minor release would be welcome, however I wait for it to actually happen before substantially altering the current RPM strategy.
OK, so that's the background. AFAICT, we (boost) don't have any way to tell if a new release breaks existing api, and whether to up the version. I think that is unfortunate. I don't really know what to do about it, though.
This is unfortunate. There is a difference between API and ABI. Not all API changes are ABI incompatible. For the record, there exists some Red Hat testing infrastructure for the boost rpms. Between 1.32.0-6 and 1.33.0-1, there were substantial ABI differences. Because of this, the SONAME was bumped in accordance to existing linux conventions. For those interested, I will attach some of these results to this email as an attachment. It is my opinion, as a mere observer and packager, that boost cares not a wit about compatibility. And you know what? This is fine with me: these are supposed to be experimental libraries and should not be constrained, design wise, with the restraints of backwards compatibility with past (flawed) experiments. Thus, packagers for each system should determine how this stuff fits together, and deal with the fallout in a way that they deem sensible. best, benjamin