16/01/2020 13:42, Ferruh Yigit:

On 1/16/2020 11:54 AM, Neil Horman wrote:

quoted

On Thu, Jan 16, 2020 at 12:25:06PM +0100, David Marchand wrote:

quoted

On Tue, Dec 17, 2019 at 2:08 PM Eelco Chaudron [off-list ref] wrote:

quoted

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.

quoted

quoted

- 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 :)