Re: [DISCUSS} Changes to TSHttpTxnErrorBodySet and TSHttpTxnSetHttpRetBody

[James Peach <jp...@apache.org>]

On Mar 25, 2014, at 11:48 PM, Nick Kew <ni...@apache.org> wrote:

> On Tue, 2014-03-25 at 20:25 -0600, Phil Sorber wrote:
> 
>>>> An API change like that affects existing plugins and could leave us
>>>> needing some ugly #ifdef crap to support both before- and after- TS
>>>> versions.  Can I make a plea to avoid that: maybe a new function name,
>>>> and migrate the old one as a #define wrapper for the new?  That applies
>>>> equally to the above with flags or to just adding the c-l-len argument.
>>> 
>>> 
>>> We have no precedence with creating new APIs and keeping old ones around,
>>> and I really feel that just adds onto an already confusing API (and
>>> somewhat defeats the purpose of this cleanup). But I also understand your
>>> concerns.
>>> 
>>> 
>> +1. We don't want to tie ourselves down to bad API's, but we also don't
>> want to strand users either. You should be able to use the 4.2.x LTS branch
>> for ~1 year still so nothing should be forcing your upgrade hastily.
> 
> That's precisely my point!
> 
> If the API loses back-compatibility, do we (as a plugin-provider)
> then support the new or the old?  Either way, our users are forced
> into a choice which, as you say, nothing should be forcing.

Is it possible to use ELF symbol versioning to keep the old API around for compatibility?

J