Neal Becker wrote:
I think it is a bit unfortunate that we don't have a system to determine whether boost updates break existing api's.
I've always been under the assumption that 1.x to 1.y release will change the binary API, and that 1.33.x to 1.33.y will not.
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.
Now if a bugfix comes out that does not change the api, be can have
libboost.so.1.33.1, which also has soname libboost.so.1, and then symlink:
libboost.so.1 -> libboost.so.1.33.1
Is that what the RPM does? It's not what the regular build does.
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.
Perhaps the misunderstanding is that we consider the "version" to be 1.33 in this case. So instead of doing above you would do: libboost.so.1.33.0 libboost.so.1.33 --> libboost.so.1.33.0 And the new patch revision would be: libboost.so.1.33.1 libboost.so.1.33 --> libboost.so.1.33.1 Basically there's no "1" version, ever. If that's not what the RedHat RPMs do I would say that's a mistake and should be corrected. -- -- Grafik - Don't Assume Anything -- Redshift Software, Inc. - http://redshift-software.com -- rrivera/acm.org - grafik/redshift-software.com -- 102708583/icq - grafikrobot/aim - Grafik/jabber.org