> -----Original Message----- > From: ext Maxim Uvarov [mailto:[email protected]] > Sent: Thursday, April 30, 2015 4:33 PM > To: Mike Holmes; Savolainen, Petri (Nokia - FI/Espoo) > Cc: [email protected] > Subject: Re: [lng-odp] [PATCH] update version number from v1.0.3 to v1.0.4 > > On 04/30/2015 14:51, Mike Holmes wrote: > > > > On 30 April 2015 at 06:55, Savolainen, Petri (Nokia - FI/Espoo) > > <[email protected] <mailto:[email protected]>> wrote: > > > > Hi, > > > > This time it is appropriate to bump the ODP_VERSION_API_MINOR, > > since "api: time: force time defines as ULL to avoid computation" > > actually changed the API signature visible to the application. But > > I question if previous increments to *API version* were necessary. > > For example, here are listed all API changes between APIs v1.0.2 > > and v1.0.3 ... > > > > git diff v1.0.2..v1.0.3 -- include/odp > > > > diff --git a/include/odp/api/version.h b/include/odp/api/version.h > > index ae1cf0d..3338559 100644 > > --- a/include/odp/api/version.h > > +++ b/include/odp/api/version.h > > @@ -46,7 +46,7 @@ extern "C" { > > * to the API. For an API with common generation and major > > version, but with > > * different minor numbers the two versions are backward > compatible. > > */ > > -#define ODP_VERSION_API_MINOR 2 > > +#define ODP_VERSION_API_MINOR 3 > > > > /** > > * Returns ODP API version string > > > > > > > > git diff v1.0.2..v1.0.3 -- platform/linux-generic/include/odp > > > > > > > > .. absolutely nothing, but still we have another API version out > > there. ODP release/validation suite/linux-generic implementation > > version can be combined into one number, but it should be > > different from the ODP API version number. Today the API version > > should be actually v1.0.1. > > > > > > Completely agree should have been bumping ODP_VERSION_IMPL_STR - not > > sure how we did not pick up on that prior. The docs dont describe that > > well either. > > > Because we also update validation test suite, which also needs it's > number increased somewhere and we have only API_MINOR for that. > > Maxim.
The validation suite must have its own version numbering scheme (separate from the API) since it will also have bugs. A suite has test cases against a specific API version (e.g. API v1.0.1), but may not be complete and may have known/unknown bugs, etc. The suite version number is bumped every time the suite is modified e.g. from v1.0.1-4 to v1.0.1-5. Basically each API version would have a matching validation suite, but we may skip some API versions and publish validation suites only for certain (good / important) API versions. E.g. a list of latest suite versions could be v1.0.1-5 (for API v1.0.1), v1.0.3-2 (for API v1.0.3), ... It's another topic if we want to combine validation suite and reference implementation (linux-generic) release cycles and version numbering ... which makes sense since it indicates on which implementation (version) the suite was tested on. -Petri _______________________________________________ lng-odp mailing list [email protected] https://lists.linaro.org/mailman/listinfo/lng-odp
