http://people.linaro.org/~mike.holmes/odp-api/html/release.html
When I paste this it works for me - not sure where it is going wrong does http://people.linaro.org/~mike.holmes/odp-api/html work for you ? - if so look at the Release Management tab. On 4 May 2015 at 15:22, Bill Fischofer <[email protected]> wrote: > 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 >> >> >> > -- 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
