Taras: - '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. You mean "compatible"?
I think it makes sense to change the API version also when making backwards compatible changes. E.g. if we are adding a function or some parameter flag but this is not worthy of a major.minor increment. An application might want to know if a specific function or feature is available. Petri: This is not equivalent to Mike's description where only the major number would be changed for incompatible changes where you write that the first two digits (or numbers) indicate (potential) backward incompatibility. I think your definition is the best. I also think the description needs to include what promises are made to the users (the applications), e.g. your two last sentences, otherwise the definition is going to be too abstract and we will come back and argue what the version numbers really means. In the mean time, changes will have been made that violate the versioning scheme. On 11 September 2014 09:25, Savolainen, Petri (NSN - FI/Espoo) < [email protected]> wrote: > 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
