The 64 bit curl_off_t patch that has recently gone in is going to cause
a binary compatibility break on platforms that have a 64 bit integer type
but a 32 bit off_t type. People who upgrade to 7.19.0 on these platforms
are going to be surprised when their apps stop working. I see a few ways
to solve this problem:

1) Ignore it. There probably aren't too many platforms like this around,
and the users will just have to deal with it in their own ways.

2) Bump the libcurl SONAME. This isn't actually necessary on platforms with
a 64 bit off_t (which is probably the majority of them these days) and will
inconvenience them (all their apps will need to be recompiled to use the
new libcurl), but at least noone will find their apps mysteriously stop
working properly.

3) Bump the libcurl SONAME, but "reserve" an older -version-info with the
older SONAME for platforms to use when they know there isn't an ABI break.
Those users would need to edit the makefile to replace the SONAME with
the reserved, compatible older one, when they know there isn't a problem.
In this case, 7.19.0 would be called libcurl.so.5.0.0 by default, but
users have the option of calling it libcurl.so.4.2.0 when they know it's
compatible. libcurl's next true SONAME break would then need to be called
libcurl.so.6.0.0 to accomodate this.

4) Same as 3, but make the reserved compatibility -version-info the default.
Users know how there is an ABI break would need to edit the makefile to
replace the SONAME with the reserved, incompatible newer one, when they
know there is a problem.

The problem with 1) is that it won't necessarily be obvious to a casual user
when there is a problem. The app may appear to work fine in some cases and
fail in others. The problem with 2) is inconvenience for the vast majority
of users for whom there isn't a break. The problem with 3) is that many
people won't realize the need for manual intervention and curse us for
a compatibility break that doesn't exist. The result will be applications
requiring libcurl.so.5.0.0 and others requiring libcurl.so.4.2.0 when they
both could just use libcurl.so.4.2.0. The problem with 4)is that many
users won't read the directions and compile an incompatible libcurl, resulting
in the problems listed under 1). With 3) and 4), we'd have to remember to
bump and document not one but two new -version-info strings for every curl
release from now until the next real SONAME break.

I'm leaning towards 4), despite the danger.

>>> Dan

-- 
http://www.MoveAnnouncer.com              The web change of address service
          Let webmasters know that your web site has moved