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. /Bruce
