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

From: Ferruh Yigit <ferruh.yigit@intel.com>
To: Bruce Richardson <bruce.richardson@intel.com>
Cc: "Kinsella, Ray" <ray.kinsella@intel.com>,
	Thomas Monjalon <thomas@monjalon.net>,
	David Marchand <david.marchand@redhat.com>,
	Luca Boccassi <bluca@debian.org>,
	Christian Ehrhardt <christian.ehrhardt@canonical.com>,
	Timothy Redaelli <tredaelli@redhat.com>,
	Kevin Traynor <ktraynor@redhat.com>, dpdk-dev <dev@dpdk.org>,
	"Laatz, Kevin" <kevin.laatz@intel.com>,
	Andrew Rybchenko <arybchenko@solarflare.com>,
	Neil Horman <nhorman@redhat.com>
Subject: Re: [dpdk-dev] How to manage new APIs added after major ABI release?
Date: Tue, 10 Dec 2019 12:40:53 +0000	[thread overview]
Message-ID: <36590631-c424-f466-cd37-a759e3fc306c@intel.com> (raw)
In-Reply-To: <20191210120455.GB103@bricha3-MOBL.ger.corp.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.