On Fri, 2020-01-17 at 09:27 +0100, David Marchand wrote: > On Thu, Jan 16, 2020 at 3:38 PM Thomas Monjalon < > tho...@monjalon.net > > wrote: > > 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 < > > > > > echau...@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 < > > > > > > echau...@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. > > Indeed, good point. > > > > > > > - 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 :) > > Luca, opinion?
I'd not only prefer it but also go as far as require it for backporting to 19.11 - experimental means experimental, but stable means stable :-) -- Kind regards, Luca Boccassi
