30/01/2020 15:21, Luca Boccassi: > On Thu, 2020-01-30 at 15:17 +0100, Thomas Monjalon wrote: > > 30/01/2020 13:57, Luca Boccassi: > > > On Thu, 2020-01-30 at 13:33 +0100, Thomas Monjalon wrote: > > > > 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?
