19/05/2020 15:26, Dumitrescu, Cristian:
> From: Yigit, Ferruh <ferruh.yi...@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.
> >
> > This patch provides aliasing by duplicating the existing and versioned
> > symbols as experimental.
> >
> > Since symbols moved from DPDK_20.0.1 to DPDK_21 block in the v20.05, the
> > aliasing done between EXPERIMENTAL and DPDK_21.
> >
> > With DPDK_21 ABI (DPDK v20.11) all aliasing will be removed and only
> > stable version of the APIs will remain.
> >
> > Fixes: 30512af820fe ("meter: remove experimental flag from RFC4115 trTCM
> > API")
> > Cc: sta...@dpdk.org
> >
> > Signed-off-by: Ferruh Yigit <ferruh.yi...@intel.com>
>
> Acked-by: Cristian Dumitrescu <cristian.dumitre...@intel.com>
>
> Thanks, Ferruh and Ray!
>
> I am OK to let this is temporarily until release 20.11.
Applied, thanks
> Regarding the API breakage larger problem,
> this method only fixes the case of experimental APIs transitioning
> to non-experimental status with no modifications,
Yes
> but it does not handle the following possible cases:
>
> 1. Experimental APIs transitioning to non-experimental status with some
> modifications.
If there is a modification, it should mature as experimental first.
> 2. Experimental APIs being removed.
No guarantee that an experimental API remains forever.
> 3. Non-experimental APIs transitioning to deprecated status.
I don't think we need to deprecate experimental API.
We can change or remove them freely at any time.
> We need a clear procedure & timing for all these cases
> to avoid similar situations in the future.
> Likely a good topic for techboard discussion.
We can ask if there are different opinions.
I think the experimental status is quite clear: no guarantee.
