On Thu, 11 Oct 2007, Dan Fandrich wrote:

> In libcurl land, you really can't tell by the libcurl version number if that
> libcurl is binary compatible or not with another libcurl version.
>
> which is true, but it's something I've felt could be fixed. Only the major
> number is ever set on the libcurl library; the two minor numbers are always
> zero.

Now you're talking about the soname numbers, right? In that ABI document I was
referring to the libcurl version number, such as 7.17.0 or 7.15.4... Perhaps I
need to clarify that.

> That means that it's impossible for someone looking at a libcurl binary
> sitting on a disk to know if it's compatible with a given application binary
> or not. Setting the minor number on each release would give each libcurl a
> unique file name that could even be cross-referenced to a source release.

Hm, yes that's true. But not all libs include all those numbers. I mean, there
are (operating) systems on which only the major number is used for example.

Still, setting the minor number so that major + minor makes a unique
combination sounds like a good idea that works for lots of platforms.

> The advice from the libtool docs contained in curl/lib/Makefile.am would
> solve this, although I think one bit of advice contained there is a too
> conservative: if any interfaces are added, then it recommends bumping the
> SONAME. The danger, of course, is that you can't mix and match libcurl
> versions with the same SONAME; you have to use a version no older than the
> one the app was built with. But bumping a minor revision number when an
> interface is added could help to reduce the incidence of an older,
> incompatible libcurl being used by mistake.

Me not having set those numbers before is mostly been just a sign of my
laziness...

-- 
  Commercial curl and libcurl Technical Support: http://haxx.se/curl.html