Hi, Agree with Taras on three levels. It's there in odp_version.h already, but we may need to revise the comments a bit.
The main digit must be reserved for ODP API generations (major reorganizations, etc). If it would be used only to indicate backward incompatibility, we'd be in ODP 15.0 in couple of months... Similarly I see that after 1.0 comes 1.1 (2.0 would be major rework of the whole thing). So, first two digits indicate (potential) backward incompatibility. Third one can be used for backward compatible changes (small additions, bug fixes, missing doxygen comments, documentation bugs, white spaces, etc). The point being that if all three are the same, it's 100% the same. If first two are the same, application compiles and runs without any change. -Petri > -----Original Message----- > From: ext Taras Kondratiuk [mailto:[email protected]] > Sent: Wednesday, September 10, 2014 6:10 PM > To: Ola Liljedahl; Mike Holmes > Cc: Savolainen, Petri (NSN - FI/Espoo); Taras Kondratiuk; lng- > [email protected] > Subject: Re: [lng-odp] [PATCH] linux-generic: version: Add macros to > compare ODP versions > > 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
