Stefan Huelswitt wrote: > On 28 May 2006 Klaus Schmidinger <Klaus.Schmidinger@xxxxxxxxxx> wrote: > >> So the question is: is it >> worth keeping the API version constant, or should I just go ahead >> and bump it up, and drop all the '#if APIVERSNUM...' stuff and >> include Stefan's fixes? > > While I see the idea behind the APIVERSION, it's quite > inefficient IMO. > > First point is, that although we have many plugins there are > still loads of patches for the VDR core available. Nearly all of > them change headerfiles (and thus the API) without changing > APIVERSION. So we have different APIs with same APIVERSION, > preteding binary compatibility which isn't always there. > > Second is, that there is only one API version for very different > types of APIs e.g. plugin API, channel API, libsi API. This leads > to the problem you face now: it's impossible to do development > (may be beside some trivial bug fixes) without changing any > header file. If you try to keep the API unchanged, it will stop > development. *) > > I think it's generaly a bad idea to hold back any bug fix, > improvement or development only to keep an API number constant. > > Recompiling the plugins is only a 'make plugins' away from > 'make' and I guess time for that is negligible. Well, that was my opinion all the time, but still there were always people complaining about having to recompile all plugins with every new version of VDR. Hence the attempt to ease this pain with the introduction of APIVERSION. > *) Situation would improve if we had different API versions for > different APIs, but we won't be able to code this to the > filename. This could be overcome, by having all plugins to > include a static struct this used APIs and their version. VDR > could check this at runtime. That would be total overkill. I guess I shouldn't have introduced APIVERSION in the first place, since, as you stated, it just takes a 'make plugins'. Oh well, so I'll bump up the API version, drop all the '#if APIVERSNUM...' stuff and include Stefan's 'libsi' fixes (which, BTW, don't touch anything the core VDR would actually use). Klaus
