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. 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 >
_______________________________________________ lng-odp mailing list [email protected] https://lists.linaro.org/mailman/listinfo/lng-odp
