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

[Thomas Monjalon]

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.