Hi,

I thought we agreed two weeks ago that API version number is three digits: 
generation.major.minor. Have that now been changed to 4 digits? Why? Or are you 
taking about implementation versioning?

Each vendor can decide how they version their implementation. Application is 
interested in the API version number. A match in generation.major would tell 
that two versions are backward compatible. So, third digit would be incremented 
for backward compatible changes. A bug fix in API may be backward compatible or 
not, depends on the bug. I think it would be decided case by case which digit 
is increment on a bug fix (e.g. a typo in documentation that gives wrong 
contract to the application but should have been understood as a typo from the 
context is a minor digit increment, etc).

-Petri


> -----Original Message-----
> From: [email protected] [mailto:lng-odp-
> [email protected]] On Behalf Of ext Maxim Uvarov
> Sent: Friday, October 24, 2014 6:58 PM
> To: [email protected]
> Subject: Re: [lng-odp] [PATCHv2] odp_version.h: Update version number
> 
> Sub version is used for post release bug fixing.
> 
> I.e.  now we go with:
> 
> v0.3.0.0
> next (no api change)
> v0.3.1.0
> next (no api change)
> v0.3.2.0
> 
> next (api change)
> v0.4.0.0
> next (no api change)
> v0.4.1.0
> 
> When v1.0.0.0 released, we will create branch, and apply only critical
> updates. I.e it will:
> v1.0.0.1
> next (no api change)
> v1.0.0.2
> next (no api change)
> v1.0.0.3
> 
> Non-linux-generic implementations just follow linux-generic tags:
> v0.3.0.0 ->  ks2v0.3.0.0 (ks2 code corresponding to lg tag).
> v1.0.0.3 -> dpdkv1.0.0.3  (dpdk version corresponding to lg tag).
> 
> Now back to your question. For apps it is important to have numbers only
> for versions which do break api. I.e. major and generation. And they are
> very transparent
> to minor and sub.
> 
> I also agree to not include sub and minor to define and keep it only in
> tags. In that case we
> will not update version each week. Less commits for versions is better :)
> 
> 
> Maxim.
> 
> 
> On 10/24/2014 11:31 AM, Savolainen, Petri (NSN - FI/Espoo) wrote:
> >
> >> -----Original Message-----
> >> From: [email protected] [mailto:lng-odp-
> >> [email protected]] On Behalf Of ext Mike Holmes
> >> Sent: Thursday, October 23, 2014 10:30 PM
> >> To: [email protected]
> >> Subject: [lng-odp] [PATCHv2] odp_version.h: Update version number
> >>
> >> Update version numnering to the ratified format.
> >> Update the number for the point release.
> >>
> >> Signed-off-by: Mike Holmes <[email protected]>
> >> ---
> >>   configure.ac                                     |  2 +-
> >>   platform/linux-generic/include/api/odp_version.h | 28
> ++++++++++++++++---
> >> -----
> >>   2 files changed, 20 insertions(+), 10 deletions(-)
> >>
> >> diff --git a/configure.ac b/configure.ac
> >> index aa94034..cc92013 100644
> >> --- a/configure.ac
> >> +++ b/configure.ac
> >> @@ -1,5 +1,5 @@
> >>   AC_PREREQ([2.5])
> >> -AC_INIT([OpenDataPlane], [0.2], [[email protected]])
> >> +AC_INIT([OpenDataPlane], [0.3.0.0], [[email protected]])
> >>   AM_INIT_AUTOMAKE([subdir-objects])
> >>   AC_CONFIG_SRCDIR([helper/config.h.in])
> >>   AM_CONFIG_HEADER([helper/config.h])
> >> diff --git a/platform/linux-generic/include/api/odp_version.h
> >> b/platform/linux-generic/include/api/odp_version.h
> >> index 3a75201..5b90e32 100644
> >> --- a/platform/linux-generic/include/api/odp_version.h
> >> +++ b/platform/linux-generic/include/api/odp_version.h
> >> @@ -23,29 +23,38 @@ extern "C" {
> >>    */
> >>
> >>   /**
> >> - * ODP API main version
> >> + * ODP API generation version
> >> + *
> >> + * Introduction of major new features or changes that make
> >> + * very significatant changes to the API. APIs with different
> >> + * versions are likely not backward compatible.
> >> + */
> >> +#define ODP_VERSION_API_GENERATION 0
> >> +
> >> +/**
> >> + * ODP API major version
> >>    *
> >>    * Introduction of major new features or changes. APIs with different
> >> major
> >>    * versions are likely not backward compatible.
> >>    */
> >> -#define ODP_VERSION_API_MAIN  0
> >> +#define ODP_VERSION_API_MAJOR 3
> >>
> >>   /**
> >> - * ODP API sub version
> >> + * ODP API minor version
> >>    *
> >>    * Introduction of additional features or minor changes. APIs with
> common
> >>    * major version and different sub versions may be backward
> compatible
> >> (if only
> >>    * additions).
> > You need to update the comment text also, e.g.:
> > Minor version is incremented when introducing backward compatible
> changes to the API. API with common generation and major version, but with
> different minor version are backward compatible.
> >
> >
> >>    */
> >> -#define ODP_VERSION_API_SUB   0
> >> +#define ODP_VERSION_API_MINOR 0
> >>
> >>   /**
> >> - * ODP API bug correction version
> >> + * ODP API sub correction version
> > Sub _correction_ version?
> >
> >>    *
> >>    * Bug corrections to the API files. APIs with the same major and sub
> >>    * versions, but different bug correction versions are backward
> >> compatible.
> >>    */
> > Usage of sub version? Generation.major.minor should define the API
> version. Sub version is used only for implementation or test cases? How?
> >
> >
> >> -#define ODP_VERSION_API_BUG   1
> >> +#define ODP_VERSION_API_SUB 0
> >>
> >>
> >>   /** @internal Version string expand */
> >> @@ -56,9 +65,10 @@ extern "C" {
> >>
> >>   /** @internal API version string */
> >>   #define ODP_VERSION_API_STR \
> >> -ODP_VERSION_TO_STR(ODP_VERSION_API_MAIN) "."\
> >> -ODP_VERSION_TO_STR(ODP_VERSION_API_SUB) "."\
> >> -ODP_VERSION_TO_STR(ODP_VERSION_API_BUG)
> >> +ODP_VERSION_TO_STR(ODP_VERSION_API_GENERATION) "."\
> >> +ODP_VERSION_TO_STR(ODP_VERSION_API_MAJOR) "."\
> >> +ODP_VERSION_TO_STR(ODP_VERSION_API_MINOR) "."\
> >> +ODP_VERSION_TO_STR(ODP_VERSION_API_SUB)
> > API version string should include only generation.major.minor.
> >
> > Some other e.g. implementation version string could be then
> generation.major.minor-sub?
> >
> >
> > -Petri
> >
> >
> > _______________________________________________
> > lng-odp mailing list
> > [email protected]
> > http://lists.linaro.org/mailman/listinfo/lng-odp
> 
> 
> _______________________________________________
> lng-odp mailing list
> [email protected]
> http://lists.linaro.org/mailman/listinfo/lng-odp

_______________________________________________
lng-odp mailing list
[email protected]
http://lists.linaro.org/mailman/listinfo/lng-odp

Reply via email to