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. Or else our plugin takes on diverging versions. One for HTTPD, one for nginx, one for trafficserver-old, one for trafficserver-new? -- Nick Kew
