On Tue, May 5, 2015 at 4:57 PM, Mike Holmes <[email protected]> wrote: > 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.
It didn't work yesterday for me either. > > 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() 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 │ Open source software for ARM SoCs >>> >>> >> > > > > -- > Mike Holmes > Technical Manager - Linaro Networking Group > Linaro.org │ Open source software for ARM SoCs > > > > _______________________________________________ > 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
