Whow ! When I started this thread, I did not think it would have become
such a troll !

One thing is sure now: there's a need to clarify the position of
libcurl's makers towards the C:R:A update strategy.

There are cases where this update cannot be C:R+1:A:
1) Changes of data shared between the caller and the library. This can
be structure changes, array sizes, variable or parameter type, etc. They
make C:R+1:A update the worst choice, since these changes can be
detected neither by the runtime linker, neither by the library, nor by
the caller.
2) External symbol changes. Although well detected on most OS, they need
soname alteration (thus not C:R+1:A) for the systems using indexes
rather than names at runtime linking (those OSes cannot detect a symbol
has changed).

Note: in the sentences above, I use "changes" in place of "addition
and/or deletion and/or alteration".

The other cases are what we can call "light incompatibilities" and leave
C:R:A update at the discretion of the makers: these are the center of
this discussion.

Soname change pros and cons:
  Pros: Avoid any targetted incompatibility
  Cons: Forces to recompile and/or relink calling applications. Tend to
stiffen a whole set of binary objects (programs + sos). Often causes the
need to have more than one version of the binary library to support
several different applications.

Impact of C:R:A update on the soname:
  On OSes using symbols at runtime linking, soname is set as C-A, thus
soname changes only when deletions or real changes occur. On OSes using
indexes for runtime linking, soname is set to C, thus it changes also
when additions are made --> more often.

Light incompatibility:
  A single release of the library might be "lightly incompatible" with
itself if compiled with different options. For example libcurl 7.19.7
with http disabled can be thought as "lightly incompatible" with libcurl
7.19.7 with http enabled, although they have the same C:R:A --> the same
soname. However, the absence of http is well detected at runtime (this
is why the incompatibility is light!).
  Libcurl 7.20.0 is fully compatible with libcurl 7.19.7 if compiled
without RTSP, SMTP, POP and IMAP. But use of one for the other is
impossible on an index-based runtime linking OS, because the soname is
not the same.
  On a symbol-based runtime linking OS (where 7.19.7 and 7.20.0 sonames
are equal), using 7.19.7 for SMTP is properly detected as an error at
runtime, clearly showing that the incompatibility is light.

For all these reasons, I really prefer to avoid an soname change on all
platforms, by using C:R+1:A when incompatibilities are light. IMHO, the
opposite causes more troubles than it offers advantages. But this is
only my own opinion...

Regards,
-------------------------------------------------------------------
List admin: http://cool.haxx.se/list/listinfo/curl-library
Etiquette: http://curl.haxx.se/mail/etiquette.html
Received on 2010-02-16