Re: [dpdk-dev] How to manage new APIs added after major ABI release?

[Ferruh Yigit <ferruh.yigit@intel.com>]

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.