[vdr] [patch] Load plugins based on VDRVERSION and APIVERSION alternatively

Clemens Kirchgatterer clemens at 1541.org
Sat Apr 22 12:51:40 CEST 2006


Klaus Schmidinger <Klaus.Schmidinger at cadsoft.de> wrote:

> APIVERSION was introduced because several people complained that
> they had to recompile all plugins every time there was even the
> slightest change in VDR. As long as none of VDR's header files has
> been changed (in a way that would cause incompatibilities) a newer
> version of VDR (which, for instance, fixes some bugs and has only
> changes in *.c files) should be able to use existing compiled
> versions of plugins. If we start using either VDRVERSION or
> APIVERSION, there will never be a clear way of handling this.
> 
> Originally I wanted to have a clear 1:1 mapping between a VDR version
> and its plugins. However, I do see that it would be good to avoid
> unnecessary recompilation. If APIVERSION isn't the right method to
> achieve this, I'd rather remove it from the final version 1.4.

i for myself always use the same version numbering scheme to distinct
between incompatible APIs in my own projects.

X.Y.Z

a raise in Z marks a compatible change in both, source code and
binary. (module can be reused without recompilation)

a changed Y marks source code compatible but not binary compatible
changes. (module has to be recompiled but needs not to be altered)

a bumped X means the meaning of the API changed in a source and binary
incompatible way. (module needs adoption and recompilation)

this scheme has the benefit of being very precise, but the drawback,
of being not feasable in very young/fast moving projects with lots of
API changes as the X number would go through the roof. but once you can
call the API rather stable, it works very well (at least for me) ;-)

best regards ...
clemens



More information about the vdr mailing list