Re: [dpdk-stable] [PATCH] meter: move RFC4115 trTCM APIs as none experimental

[Thomas Monjalon <thomas@monjalon.net>]

16/01/2020 13:42, Ferruh Yigit:
> On 1/16/2020 11:54 AM, Neil Horman wrote:
> > On Thu, Jan 16, 2020 at 12:25:06PM +0100, David Marchand wrote:
> >> On Tue, Dec 17, 2019 at 2:08 PM Eelco Chaudron <echaudro@redhat.com> wrote:
> >>>
> >>> Moved RFC4115 APIs to none experimental as they have been there
> >>> since 19.02. Also, these APIs are the same as the none RFC4115 APIs.
> >>>
> >>> Signed-off-by: Eelco Chaudron <echaudro@redhat.com>
> >>
> >> There is a discussion on the OVS ml at the moment to get these symbols
> >> in the stable ABI for 19.11.
> >> I want to understand how this would be done.
> >>
> >> - I take this patch in 20.02, these symbols are added in the 20.0.1 ABI.
> >> On the other hand, the 19.11 release maintains the 20.0 ABI.
> >>
> >> Does it mean the backport adds these symbols with the 20.0 version in
> >> the 19.11 branch?
> >> Or is 20.0.1 version acceptable / a thing we want?

We cannot have the symbol with different versions in different releases,
otherwise the compatibility is broken when upgrading.
So we have no choice, the symbol must have version 20.0.1
in release 19.11.1, as in release 20.02.


> >> - These symbol already existed in the 20.0 ABI, versioned as EXPERIMENTAL.
> >> We can go and remove these entries since we are not bound to preserve
> >> the experimental APIs.
> >> But, on the other hand, nothing should prevent us from keeping some
> >> aliases so that the symbols versioned EXPERIMENTAL are still available
> >> to existing users.
> >>
> > I would say that choice is up to you.  If you want to alias them to be nice to
> > prior users, thats fine by me. But experimental means experimental, and so users
> > have to be prepared to rebuild when things change, even if that change is
> > changing the version from experimental to a concrete version.
> > 
> 
> I would prefer to keep the alias and don't break the existing users, specially
> for the case experimental API is becoming mature without change.

I agree, it's cool to be nice :)