Re: [dpdk-dev] [PATCH v4] meter: provide experimental alias of API for old apps

[Thomas Monjalon <thomas@monjalon.net>]

18/05/2020 13:48, Ray Kinsella:
> On 18/05/2020 11:46, Thomas Monjalon wrote:
> > 18/05/2020 11:30, Ray Kinsella:
> >> On 18/05/2020 10:22, Thomas Monjalon wrote:
> >>> 18/05/2020 08:29, Ray Kinsella:
> >>>> On 17/05/2020 20:52, Dumitrescu, Cristian wrote:
> >>>>> From: Yigit, Ferruh <ferruh.yigit@intel.com>
> >>>>>>
> >>>>>> On v20.02 some meter APIs have been matured and symbols moved from
> >>>>>> EXPERIMENTAL to DPDK_20.0.1 block.
> >>>>>>
> >>>>>> This can break the applications that were using these mentioned APIs on
> >>>>>> v19.11. Although there is no modification on the APIs and the action is
> >>>>>> positive and matures the APIs, the affect can be negative to
> >>>>>> applications.
> >>>>>>
> >>>>>> Since experimental APIs can change or go away without notice as part of
> >>>>>> contract, to prevent this negative affect that may occur by maturing
> >>>>>> experimental API, a process update already suggested, which enables
> >>>>>> aliasing without forcing it:
> >>>>>> https://patches.dpdk.org/patch/65863/
> >>>>>>
> >>>>>
> >>>>> Personally, I am not convinced this is really needed.
> >>>>>
> >>>>> Are there any users asking for this?
> >>>>
> >>>> As it happens it is all breaking our abi regression test suite.
> >>>> One of the things we do is to run the unit tests binary from v19.11 against the latest release. 
> >>>>  
> >>>>> Is there any other library where this is also applied, or is librte_meter the only library?
> >>>>
> >>>> librte_meter is the only example AFAIK. 
> >>>> But then we only have one example of needing symbol versioning also at the moment (Cryptodev).
> >>>>
> >>>> This is going to happen with experimental symbols that have been around a while, 
> >>>> that have become used in applications. It is a non-mandatory tool a maintainer can use
> >>>> to preserve abi compatibility.
> >>>
> >>> If you want to maintain ABI compatibility of experimental symbols,
> >>> it IS a mandatory tool.
> >>> You cannot enforce your "ABI regression test suite" and at the same time
> >>> say it is "non-mandatory".
> >>>
> >>> The real question here is to know whether we want to maintain compatibility
> >>> of experimental symbols. We said no. Then we said we can.
> >>> The main concern is the message clarity in my opinion.
> >>>
> >>
> >> There is complete clarity, there is no obligation. 
> >> Our lack of obligation around experimental, is upfront in the policy is upfront in the policy.
> >>
> >> "Libraries or APIs marked as experimental may change without constraint, as they are not considered part of an ABI version. Experimental libraries have the major ABI version 0."
> >>
> >> Later we give the _option_ without obligation to add an alias to experimental.pls see the v6.
> >>
> >> +   - In situations in which an ``experimental`` symbol has been stable for some
> >> +     time. When promoting the symbol to become part of the next ABI version, the
> >> +     maintainer may choose to provide an alias to the ``experimental`` tag, so
> >> +     as not to break consuming applications.
> >>
> >> So it is something a Maintainer, _may_ choose to do.
> >> I use the word, "may" not "will" as there is no obligation's associated with experimental.
> > 
> > 
> > OK Ray, this is my understanding as well.
> > 
> > The only difficult part to understand is when claiming
> > "it is all breaking our abi regression test suite"
> > to justify the choice.
> 
> Justification, is the same as any other consumer of DPDK saying you broke my APP.
> 
> > As the maintainer (Cristian) says he does not like this change,
> > it means the regression test suite should skip this case, right?
> 
> So the regression test run the v19.11 Unit Test's against the v20.05 rc.
> My thought was that would provide reasonably good coverage of the ABI to catch more subtly regression.
> Those regressions that affect the behavior of the ABI (the contract), instead of ABI itself. 

I understand the goal.
And I think, because of this goal, you will try to maintain ABI compat
of *ALL* experimental symbols maturing as stable symbol.