On Thu, 2020-01-30 at 16:55 +0100, Thomas Monjalon wrote:

30/01/2020 15:21, Luca Boccassi:

quoted

On Thu, 2020-01-30 at 15:17 +0100, Thomas Monjalon wrote:

quoted

30/01/2020 13:57, Luca Boccassi:

quoted

On Thu, 2020-01-30 at 13:33 +0100, Thomas Monjalon wrote:

quoted

Hi,

I disagree with the need of this patch.
The symbol was experimental, meaning we can change it.
Removing experimental tag is not an ABI break.

Hi,

This symbol change was requested for backport in 19.11.x, and
experimental or not I'm not too keen on backward incompatible
changes
to the public interface in an _LTS point release_. The
compromise
was
to see if we could support both symbols version, which makes
the
change
backward compatible.

If you prefer not to have this patch in mainline I'm also fine
in
taking it just for the LTS. I agree with you that it is not
required
for mainline releases (although nicer for me if it's a backport
rather
than a new change).

I would like to avoid opening the door for maintaining the
experimental ABI
in the mainline. Please take it directly in the LTS.

The next question is to know whether we really want to have such
patch in LTS.
Anyway, 19.11.0 has this symbol as experimental.
How adding a non-experimental version of the function in 19.11.1
will
change
the ABI status of the whole 19.11 branch?

The problem is not adding the new symbol, but removing the
experimental
one. Changing the version of the symbol was requested by OVS for
inclusion in 19.11.

Yes, sorry, this is what I meant.
Given 19.11.0 already has the symbol as experimental,
and that applications like OVS had to accept it as experimental,
why removing experimental tag in 19.11.1?

I think it was mentioned that it was preferred not to suppress the
compiler warning to avoid any accidental use in the future, but the OVS
maintainer(s) should answer as I might remember wrongly.

-- 
Kind regards,
Luca Boccassi