On 8/20/2014 4:42 PM, Daniel Stenberg wrote:
> 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.

100% understood. And we don't plan to go 10+ versions between upgrades
again, that's for sure.

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

Okay, good. There was some fear on our end that our expectations were
completely incorrect, and that we might have to deal with these
regularly; I'm glad that's not the case!

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

That's a fair point.

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

Looking at your previous statement:

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

Have you considered having the client tell you which version of the cURL
library they were compiled (and, theoretically, tested) against? For
example, during one of the global/easy/multi_init()s, a client could
pass the "functional version" of the library that it expects. A bit like
an SONAME, but enforced by you instead of the linker. Every time you
have to make one of these tough calls -- where making the codebase
better for new clients breaks old clients -- you'd then have a tool to
help you out, because libcurl _knows_ which behavior the client expects.

I've only seen this in practice on much smaller libraries, so I'm not
sure how well it would scale. And its only utility is in cases like
this, where you want to change new client behavior but leave old clients
alone. For it to be useful, you'd have to have enough cases like this to
justify the additional complexity, but not so many that your codebase is
just littered with version checks...

And of course, for all I know, this idea may have been naively proposed
many times before, but it seemed like it was worth mentioning. :)

Thanks again for your input.

Jacob Champion
LabVIEW R&D
National Instruments
-------------------------------------------------------------------
List admin: http://cool.haxx.se/list/listinfo/curl-library
Etiquette: http://curl.haxx.se/mail/etiquette.html
Received on 2014-08-22