11/12/2019 14:11, Neil Horman: > On Tue, Dec 10, 2019 at 11:56:28AM +0000, Ferruh Yigit wrote: > > Hi, > > > > With new process, the major ABI releases will be compatible until it is > > deprecated (until next LTS for now), > > like current ABI version is 20 in DPDK_19.11 and DPDK versions until > > DPDK_20.11 > > will be ABI compatible with this version. > > > > But if we introduce a new API after major ABI, say in 20.02 release, are we > > allowed to break the ABI for that API before DPDK_20.11? > > > > If we allow it break, following problem will be observed: > > Assume an application using .so.20.1 library, and using the new API > > introduced > > in 20.02, lets say foo(), > > but when application switches to .so.20.2 (released via DPDK_20.05), > > application > > will fail because of ABI breakage in foo(). > > > > I think it is fair that application expects forward compatibility in minor > > versions of a shared library. > > Like if application linked against .so.20.2, fair to expect .so.20.3, > > .so.20.4 > > etc will work fine. I think currently only .so.20.0 is fully forward > > compatible. > > > > If we all agree on this, we may need to tweak the process a little, but > > before > > diving into implementation details, I would like to be sure we are in same > > page. > > > Yes, I agree with the assertion. Once an ABI is fixed, it must be compatible > with all future minor releases subsequent to the fixing of that ABI, until the > next major update. That is to say, once you release ABI_20, all minor updates > 20.01, 20.02, etc must be compatible with ABI_20 until such time as ABI_21 is > released.
The question of Ferruh was about compatibility of 20.2 vs 20.1, given both are compatible with 20.0 of course. The question makes sense if a new symbol is added in 20.1. And yes I think the symbol added in a minor version must be kept until the next major ABI.
