On Wed, 20 Aug 2014, Jacob Champion wrote:

>> What's a bug and what's an ABI/API breakage often leads to a judgement
>> call.
>
> Do you have a gut feel for which way that judgment call typically goes,
> specifically for CURLOPT compatibility? Or is it truly case-by-case?

I would say they're often on an even more subtle level than so obviously about
how a particular CURLOPT is supposed to work or not. But yeah, I'm afraid I
don't have or know any particular pattern that tends to come up. They're much
like bugs - they appear in all different shapes and forms.

> And are those discussions just something we need to keep an eye out for on
> the curl-library list, or do they happen somewhere else?

Everything imortant that concerns libcurl development as far as I am concerned
shows up here. That's also what I keep telling everyone who emails me
privately, who sends pull requests on github and even quite a few poeple who
ask detailed questions on sites like stackoverflow.com.

We're around 1400 libcurl hackers and users here.

> Typically we'll follow the strategy of "write the smallest amount of code
> that works", to reduce maintenance and make it harder to write cargo cult
> code.

I think that's a good strategy and I'm convinced most libcurl users go about
it that or a similar way.

> So for us, retroactively adding CURLOPTs to the "minimum list" required for
> any given task is an API break. And in our ideal world, that would never
> happen without an SONAME change. But I'm trying to recalibrate that
> expectation into something more in line with what the library's actual
> policy is; hence my earlier questions.

Yes well, but there's the question: in this case you got a feature that was
earlier sort of implied without you using the proper option and that was a
mistake in the libcurl code. My mistake actually, and quite likely because
SMTP was still fairly early in its support and I was forward-thinking enough
in the initial implementation.

We made a call. SMTP was early and not terribly many were using it
(supposedly). Doing a quirky or kludgy work-around to survive without the
option didn't feel right. And changing SONAME for something like this - that
we consider rather minor in the big scheme of things - was completely out of
the question. If bumping SONAME is the answer, then we must change the
question basically.

This is not the only example of us fixing a bug that has some repercussions
for applications. It is the unfortunate downside of having a bazillion of
users and library with hundreds of run-time options and thousands of
build-time combinations.

Also and I will stress this again, we NEED and RELY ON people to speak up and
argue for taking a different route at the time of the decision or at least
very close in time. When years have passed after a change, switching back is
not an option anymore either.

So I think you had the right expectations and the right approach to API usage.
You just had bad luck and got bitten. If you ask me, the risk of it happening
again (for you) is very slim.

> All that aside, _if_ one of these breaks is necessary, we'd really like to
> have a big red flag put into the upgrade notes.

We have obviously failed to mention this fact clearly in the changelog on the
site - but we should.

> It'd also be nice to have a baseline guarantee of _some_ level of functional
> compatibility, in addition to the current API and ABI guarantees. Even
> something like "libcurl will not break the example code emitted by past
> versions of the curl executable, except in critical situations such as
> security vulnerabilities" would go a long way to help us avoid situations
> like this.

I would expect that 99% of all programs that were written to use libcurl in
October 2006 (after we did our last SONAME bump) can still be compiled against
a modern libcurl. Or simply be made to load a new libcurl at run-time without
rebuilding anything. That's not a mistake, that's the result of very hard work
and determinism to maintain the ABI and API.

You fell into this hole in the road and now you want to make sure we don't
accidentally make another hole in the future.

I don't think adding any more guarantees or policies will help to that goal.
We already have our set policies, our goals and I think we work to keep those.
There can still be mistakes made - especially since what is a mistake and what
is correct is highly subjective.

I don't think we can guarantee that old example source codes will work for two
reasons: A) we can't gurantee we haven't made mistakes in them and B) we don't
have any good ways to test the example source codes - we have test cases for
that.

But I'm open to ideas or suggestions if someone has ideas around how we can
improve in this area.

> For what it's worth, we think it's a great product, and has been for some
> time now. Thanks for your work on it, and for your quick response!

Thanks. For what it's worth: I highly appreciate your feedback and criticism.
Giving our ways, methods and policies a closer look and re-evaluation is a
good thing and we should do it more often.

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