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.
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. How is Linux/Unix handling similar *interface* versioning, e.g. X server interface? The X server interface has one version, the X server implementation (and there is or at least was more than one) has another version from different version sequence. -- Ola On 5 September 2014 17:06, Mike Holmes <[email protected]> wrote: > > - Major version numbers change whenever there is something > significant, a large or potentially backward-incompatible change to a > software package. > - Minor version numbers change when a new, minor feature is > introduced, or when a set of smaller features is rolled out. > - Patch numbers change when a new build of the software is released to > customers. This is normally for small bugfixes or the like. > > > > On 5 September 2014 10:54, Ola Liljedahl <[email protected]> wrote: > >> Good idea. >> What's the strict meaning of the a/b/c numbers? I would like to see a >> definition on how these numbers change when you make common changes. >> E.g. >> add function or type >> remove function or type >> syntactical change (but same semantics so functionally backwards >> compatible), maybe adding an argument or change in header files >> semantic change (but same syntax so existing code would compile but >> perhaps not run as expected) >> other cases? >> >> -- Ola >> >> >> >> >> On 5 September 2014 15:51, Taras Kondratiuk <[email protected]> >> wrote: >> >>> API and header names will evolve and change continuously. Some changes >>> may be not backward compatible. Application need some mechanism to >>> support at least a few recent revisions of ODP API. Hence add a few >>> macros to be able to compare ODP API versions. >>> >>> Macros can be used in a following way: >>> >>> #include <odp_version.h> >>> #if ODP_VERSION_API >= ODP_VERSION(2,0,0) >>> /* Call ODP v2.0 API */ >>> #elif ODP_VERSION_API >= ODP_VERSION(1,0,0) >>> /* Call ODP v1.0 API */ >>> #else >>> /* Call pre v1.0 API */ >>> #endif >>> >>> Signed-off-by: Taras Kondratiuk <[email protected]> >>> Signed-off-by: Taras Kondratiuk <[email protected]> >>> --- >>> platform/linux-generic/include/api/odp_version.h | 16 ++++++++++++++++ >>> 1 file changed, 16 insertions(+) >>> >>> diff --git a/platform/linux-generic/include/api/odp_version.h >>> b/platform/linux-generic/include/api/odp_version.h >>> index c823e2d..97f8e26 100644 >>> --- a/platform/linux-generic/include/api/odp_version.h >>> +++ b/platform/linux-generic/include/api/odp_version.h >>> @@ -44,6 +44,22 @@ extern "C" { >>> */ >>> #define ODP_VERSION_API_BUG 1 >>> >>> +/** >>> + * Macro to merge three parts of ODP API version into one word >>> + * >>> + * Merge ODP version into one word: >>> + * byte 0 - bug correction version >>> + * byte 1 - sub version >>> + * byte 2 - main version >>> + */ >>> +#define ODP_VERSION(a, b, c) (((a) << 16) + ((b) << 8) + (c)) >>> + >>> +/** >>> + * Current version of ODP API in one word form >>> + */ >>> +#define ODP_VERSION_API ODP_VERSION((ODP_VERSION_API_MAIN), \ >>> + (ODP_VERSION_API_SUB), \ >>> + (ODP_VERSION_API_BUG)) >>> >>> /** @internal Version string expand */ >>> #define ODP_VERSION_STR_EXPAND(x) #x >>> -- >>> 1.7.9.5 >>> >>> >>> _______________________________________________ >>> lng-odp mailing list >>> [email protected] >>> http://lists.linaro.org/mailman/listinfo/lng-odp >>> >> >> >> _______________________________________________ >> lng-odp mailing list >> [email protected] >> http://lists.linaro.org/mailman/listinfo/lng-odp >> >> > > > -- > *Mike Holmes* > Linaro Technical Manager / Lead > LNG - ODP >
_______________________________________________ lng-odp mailing list [email protected] http://lists.linaro.org/mailman/listinfo/lng-odp
