On 09/10/2014 05:35 PM, Ola Liljedahl wrote:
I think we should separate between ODP implementations and the ODP API. Users (applications) are primarily interested in the API. Any API changes can be separated into backwards and not backwards compatible changes. I think a major.minor designation for the ODP API is sufficient (there is no patch level of the API specification or?). The major number changes for any incompatible changes (with minor number reset), the minor number changes for any backwards compatible change (with major number kept). Small or big change is not relevant.
I had in mind a bit different schema: major.minor.sub. - 'major.minor' is an official ODP release version, like v1.0 we are going to have by EOY. - 'sub' is a version that must be incremented on each incompatible API change (syntax or semantics) between releases. It is reset on each major.minor change. IMO there is no point to change API version for backward compatible changes.
One can imagine an application that attempts to handle changes (bugs and bug fixes) in the ODP implementation by checking which version (including the C number as defined below) the implementation is at. But this will be difficult with ODP since there will be multiple implementations and those can and will likely have different version sequences. The application would also need a mean to identify which ODP implementation it is using.
Currently ODP_VERSION_API* macros address only API versions. Adding versions for implementation is a separate story. To use it we may need a way for application to detect which implementation is used. Maybe expose define like ODP_PLATFORM_LINUX_GENERIC. _______________________________________________ lng-odp mailing list [email protected] http://lists.linaro.org/mailman/listinfo/lng-odp
