Thanks all, agree with all the comments Also to be specific test changes should be -sub number changes only right ? I will update the arch doc patch too to make things clearer.
Mike On 24 October 2014 11:57, Maxim Uvarov <[email protected]> wrote: > 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 > -- *Mike Holmes* Linaro Sr Technical Manager LNG - ODP
_______________________________________________ lng-odp mailing list [email protected] http://lists.linaro.org/mailman/listinfo/lng-odp
