On Tue, 19 Aug 2014, Jacob Champion wrote:
2) Does libcurl have a policy on behavioral compatibility?
Yes we have a policy: we don't break ABIs and we don't break APIs.
In reality of course things are harder and not always as good as we'd like
them to be. I've previously clarified my stand-point somewhat in this
blogpost: http://daniel.haxx.se/blog/2013/03/23/why-no-curl-8/
From what I can tell from the previous conversations [2] on the topic, the
official statement seems to be that any SMTP client that wasn't setting
CURLOPT_UPLOAD was buggy. I'm fine with that, if that's the answer (and
we'll be adding CURLOPT_UPLOAD to our new client code). But as someone
looking in from the outside, it seems like it was sort of a retroactive
decision -- especially since the libcurl SMTP examples didn't have it
either.
What's a bug and what's an ABI/API breakage often leads to a judgement call.
We discuss it, we take a decision and we move on. Sometimes not everyone agree
on the way we dealt with a specific issue.
Put another way: How do I ensure that our current libcurl client code
(HTTP, SMTP, or otherwise) does not contain other bugs of this nature,
so that we won't break in the future because of a missing CURLOPT?
You participate on the mailing list when such issues occur and you speak up
your mind if you disagree with the direction in which we're going. Or you
help us write up more test cases that make sure we maintain certain behaviors.
And you file bug reports when you find bugs and problems.
We're (without me being able to speak for anyone else besides myself of
course) determined to keep doing a great product but we of course depend on
people to actually make sure it stays this way.
--
/ daniel.haxx.se
-------------------------------------------------------------------
List admin: http://cool.haxx.se/list/listinfo/curl-library
Etiquette: http://curl.haxx.se/mail/etiquette.html
