Klaus Schmidinger <Klaus.Schmidinger@xxxxxxxxxx> 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
