On 12/10/2019 12:04 PM, Bruce Richardson wrote: > 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. >> > > Well, any new API's generally come in as experimental, in which case > changes are allowed, and breakage can be expected. If they are not > experiemental, then the ABI policy applies to them in that they cannot > change since they are part of the .21 ABI, even if that ABI is not fully > complete yet. For any application only using stable, non-experimental > functions, forward compatibility must be maintained IMHO. >
Talking about not experimental APIs, experimental ones free from the process. And when and API added in 20.02 (ABI_20.1) it is kind of still ABI_20, because it should be supported for following ABI_20.x, instead of calling it ABI_21, and this minor tweak (and mind shift) in .map files can be our solution.
