On Fri, 12 Feb 2010, Patrick Monnerat wrote:

> 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.

Exactly. And my reasoning was this: we added CURLOPT_* options in 7.20.0 that
didn't exist before. So when an app comes along and starts to use them. Now,
that app cannot just go back and use an older lib anymore. They are not
compatible in that sense.

Apps that only use older options can of course switch to an older version
easily, but we can't really make a distiction with this kind of API. If we
would have an API with plain function calls instead of setopt() options, it
would make the case crystal clear.

> 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
> :-/)

That's where we're not quite in agreement. But this is not a strong position
of mine. As I said: I've done this wrong so many times that people probably
are used to libcurl.sos having the same numbers between versions even though
we've added options.

-- 
  / daniel.haxx.se
-------------------------------------------------------------------
List admin: http://cool.haxx.se/list/listinfo/curl-library
Etiquette:  http://curl.haxx.se/mail/etiquette.html