Daniel Johnson wrote:

> On Feb 11, 2010, at 4:41 PM, Daniel Stenberg wrote:

>> # 1. if there are only source changes, use C:R+1:A
>> # 2. if interfaces were added use C+1:0:A+1
>> # 3. if interfaces were removed, then use C+1:0:0

>> One uncertainty to define is perhaps what 'interface' means in this
context.
>>
>> I take it you say my reasoning is wrong and that (1) is the rule I
should've followed this time?

Yes. But this is no blame !

> "Interface" would refer to the library's ABI. So if an externally
visible function or struct is added, #2 would apply. If a function or
struct is changed or deleted, #3 applies. Otherwise, it should be #1. A
"changed" function refers to its parameter list, just to be clear.

Totally agreed. The goal of this numbering is to avoid a runtime use of
a library that is not compatible with the one used at link time.
There are several levels of "compatibility": the most important one is
the system level. The way the system resolves solinks at (pre)runtime is
mandatory to consider:

_ On most OSes, this is resolved by a name (symbol) table lookup.
Inserting new symbols in this table or reordering it within a new
library release does not break existing binary programs. Thus soname can
be derived from (C-A)
_ On some others (like OS400), names are not used at runtime resolving:
instead, table index or some other indirection means are used. System
compatibility between 2 library versions exists then only if the solinks
table is unchanged (i.e.: no reordering, no append, no delete, no
insert). In that case, soname must be computed from (C) alone.

The second compatibily level is the prototype level: on most OSes it
does not impact the system table itself (except when names are mangled,
like in C++, resulting in a name change!), but a prototype change
effectively breaks the compatibility in all cases. Rule number #3
applies then.

The next compatibility level is the semantics level: in our case, some
semantic additions have been done. As D. Johnson says, rule #1 should
have been used instead of #2, because there is no change here that makes
the library "more incompatible" with the previous release than having
the same release of the library compiled twice, but with different
compilation options (I hope you understand what I mean: this sentence is
not very clear :-/)

This C:R:A numbering has not been designed with semantics
incompatibilies in mind (by the way, I've never found a real design note
on it, only some notes like this one). If semantics incompatibilities
are important (i.e.: to the designer), then rule #2 should be used
instead of #1 each time there is at least a new behavior in the lib
(i.e.: each time there is a new curl_easy_setopt() option); likewise,
rule #3 would apply as soon as an option disappears... resulting in an
soname change on ALL OSes. This is left at your appreciation...

I cannot imagine the use of (R): probably for doc purposes and/or soname
future extension.
-------------------------------------------------------------------
List admin: http://cool.haxx.se/list/listinfo/curl-library
Etiquette: http://curl.haxx.se/mail/etiquette.html
Received on 2010-02-12