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