On Wed, Aug 10, 2016 at 6:22 AM, Anders Roxell <[email protected]>
wrote:

> On 10 August 2016 at 09:33, Maxim Uvarov <[email protected]> wrote:
> > On 08/09/16 22:26, Anders Roxell wrote:
> >>
> >> On 9 August 2016 at 08:54, Maxim Uvarov <[email protected]>
> wrote:
> >>>
> >>> On 08/09/16 02:36, Mike Holmes wrote:
> >>>>
> >>>>
> >>>>
> >>>> On 8 August 2016 at 03:01, Maxim Uvarov <[email protected]
> >>>> <mailto:[email protected]>> wrote:
> >>>>
> >>>>      On 08/05/16 21:27, Anders Roxell wrote:
> >>>>
> >>>>          On 2016-08-03 11:40, Maxim Uvarov wrote:
> >>>>
> >>>>              Signed-off-by: Maxim Uvarov <[email protected]
> >>>>              <mailto:[email protected]>>
> >>>>              ---
> >>>>              configure.ac <http://configure.ac> | 4 ++--
> >>>>                1 file changed, 2 insertions(+), 2 deletions(-)
> >>>>
> >>>>              diff --git a/configure.ac <http://configure.ac>
> >>>>              b/configure.ac <http://configure.ac>
> >>>>              index c0eb207..bd16370 100644
> >>>>              --- a/configure.ac <http://configure.ac>
> >>>>              +++ b/configure.ac <http://configure.ac>
> >>>>
> >>>>              @@ -12,10 +12,10 @@ AM_SILENT_RULES([yes])
> >>>>
> >>>>
> >>>> ############################################################
> ##############
> >>>>                # Set correct platform library version
> >>>>
> >>>>
> >>>> ############################################################
> ##############
> >>>>              -ODP_LIBSO_VERSION=110:0:1
> >>>>              +ODP_LIBSO_VERSION=111:0:0
> >>>>                AC_SUBST(ODP_LIBSO_VERSION)
> >>>>                -ODPHELPER_LIBSO_VERSION=110:0:1
> >>>>              +ODPHELPER_LIBSO_VERSION=111:0:0
> >>>>                AC_SUBST(ODPHELPER_LIBSO_VERSION)
> >>>>
> >>>>          The SO-version doesn't need to change. The SO-version only
> >>>>          needs to be
> >>>>          changed when an interface has been added, removed, or
> modified
> >>>>          since
> >>>>          the last update [1].
> >>>>
> >>>>          For this release the API version should be changed and we
> >>>>          should change
> >>>>          the version in include/odp/api/spec/version.h.
> >>>>
> >>>>          Cheers,
> >>>>          Anders
> >>>>          [1]
> >>>>
> >>>>
> >>>> https://www.gnu.org/software/libtool/manual/html_node/
> Updating-version-info.html
> >>>>
> >>>>
> >>>> <https://www.gnu.org/software/libtool/manual/html_node/
> Updating-version-info.html>
> >>>>
> >>>>
> >>>>      Yes, but it's looks like very strange for me if .so version
> >>>>      110:0:0 and odp version is 1.11.0.0.
> >>>>      I think that also can be confusing for other people and not clear
> >>>>      how to patch .so version
> >>>>      to tag in git repo.
> >>>>
> >>>>
> >>>> It should not be confusing for people, linux is very specific about
> the
> >>>> rules for a .so version.
> >>>> We are trying to be very specific in our API release numbering doc.
> >>>> On OS "wherever" you can be completely sure the API number will not
> >>>> match
> >>>> that OS'es mechanisms for version libraries.
> >>>>
> >>> I'm not big expert in deploying .so to mainline. But I'm agree with
> Bill
> >>> that .so version should match to api and tar ball name.
> >>
> >> No it should not.
> >> Projects building on top of ODP shouldn't have to rebuild if we do a
> >> new release that only adds new APIs.
> >
> > ok, that is logical.
> >
> >> The only time they should have to rebuild is if we break ABI (delete
> >> or rename an API).
> >
> > ok, we change TM API:
> > https://git.linaro.org/lng/odp.git/commitdiff/
> a560c609e78716421e782aa388805937d177ef0e?hp=524987a32f9873e59ce265ffba6e83
> 1e756a2441
>
> I didn't know that this was in.
> aha tricky, the deb build process should notice changes like this but
> since it
> was in a union it got hidden or the size was the same it didn't find it.
>

I'm not an expert on deb packaging, but the real change here is that the
effective type signature of odp_tm_create() was changed by this update. I'm
not sure how the scanner determines that an ABI break but it sounds like it
isn't considering changes to fields within structs that are passed as
parameters.


>
> >>
> >> When a new version of a library is binary-incompatible with the old
> >> one the SO-version needs to change.
> >
> >
> > yes, 1.10 is incompatible to 1.11, we need to change version.
>
> I agree, since we did the change in the union.
>
> Thank you for pointing that out.
>
> if we only added this "odp_bool_t egress_fcn_supported;",
> that would only be a "age" bump.
>
> Cheers,
> Anders
>
> >
> >>
> >> Again, did you read the link I pasted in the other email [1] ?
> >> Especially this snippet: "Never try to set the interface numbers so
> >> that they correspond to the release number of your package. ..."
> >>
> >>
> >> Cheers,
> >> Anders
> >> [1]
> >> https://www.gnu.org/software/libtool/manual/html_node/
> Updating-version-info.html
> >
> >
> > Ok, than numbers has to correspond only to API. I.e. first 2 digits in
> our
> > API code.
> >
> > From doc -release option is not clear where is has to be set.
> > """
> > Instead, use the -release flag (see Release numbers
> > <https://www.gnu.org/software/libtool/manual/html_node/
> Release-numbers.html#Release-numbers>),
> > but be warned that every release of your package will not be binary
> > compatible with any other release.
> > """
> > is it set by autotools automatically somewhere or we should add it to
> > configure.ac also?
> >
> > Maxim.
> >
>

Reply via email to