On 4 May 2015 at 07:31, Bill Fischofer <[email protected]> wrote:
> I had suggested last year that we number the APIs to reflect architectural > changes but that implementations use a build number to indicate service > changes. So you'd say something like "I'm running odp-dpdk v1.1 build 16" > or "I'm running validation suite v1.3 build 4" to make the distinction > clear. > I think the need for would be covered by odp_version_impl_str() <http://people.linaro.org/~mike.holmes/odp-api/html/group__odp__ver__abt__log__dbg.html#gab6931e3029d875bfef5012d076468849> we have not been using it however. It should increment for any change at all when tagged. I have updated the api-doc material on versioning - here is a 1st pass cut rendered as html, it still needs a touch up here and there http://people.linaro.org/~mike.holmes/odp-api/html/release.htm > If you want to have a single number than the last digit is the build > number, but then that also seems to keep needing to be explained so it's > simpler to explicitly state the build number as a separate designator. > > On Mon, May 4, 2015 at 4:52 AM, Savolainen, Petri (Nokia - FI/Espoo) < > [email protected]> wrote: > >> >> >> > -----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 >> > > -- Mike Holmes Technical Manager - Linaro Networking Group Linaro.org <http://www.linaro.org/> *│ *Open source software for ARM SoCs
_______________________________________________ lng-odp mailing list [email protected] https://lists.linaro.org/mailman/listinfo/lng-odp
