Mike, your last URL gives a "Not Found" result. On Mon, May 4, 2015 at 9:52 AM, Mike Holmes <[email protected]> wrote:
> > > 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
