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. Just my two cents. Regards. *) 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. -- Stefan Huelswitt s.huelswitt@xxxxxx | http://www.muempf.de/
