On Mar 25, 2014, at 11:48 PM, Nick Kew <n...@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
