Our only commitment is to the stability of the v19.11/v20 ABI, until v21.
That said, once an ABI migrates from EXPERIMENTAL to v21, it _shouldn't_ be changing. We don't have a strict commitment to the v21 ABI until v20.11. However if v21 is changing across quarterlies (outside of additions) ... something else is wrong. Ray K On 20/04/2020 17:59, Trahe, Fiona wrote: > Gentle reminder that we still haven't come to a consensus about > whether ABI compatibility is required across quarterly releases or not. > See below. > >> -----Original Message----- >> From: Trahe, Fiona <[email protected]> >> Sent: Friday, April 17, 2020 12:47 PM >> To: Ray Kinsella <[email protected]>; Thomas Monjalon <[email protected]>; >> Richardson, Bruce >> <[email protected]> >> Cc: [email protected]; Kusztal, ArkadiuszX <[email protected]>; Neil >> Horman >> <[email protected]>; Luca Boccassi <[email protected]>; Kevin Traynor >> <[email protected]>; Yigit, Ferruh <[email protected]>; Trahe, Fiona >> <[email protected]> >> Subject: RE: [dpdk-dev] [PATCH] cryptodev: version rte_cryptodev_info_get >> function >> >> Hi all, >> >>> -----Original Message----- >>> From: Ray Kinsella <[email protected]> >>> Sent: Friday, April 17, 2020 11:34 AM >>> To: Thomas Monjalon <[email protected]>; Richardson, Bruce >>> <[email protected]> >>> Cc: Trahe, Fiona <[email protected]>; [email protected]; Kusztal, ArkadiuszX >>> <[email protected]>; Neil Horman <[email protected]>; Luca >>> Boccassi >>> <[email protected]>; Kevin Traynor <[email protected]>; Yigit, Ferruh >>> <[email protected]> >>> Subject: Re: [dpdk-dev] [PATCH] cryptodev: version rte_cryptodev_info_get >>> function >>> >>> >>> >>> On 17/04/2020 11:17, Thomas Monjalon wrote: >>>> 17/04/2020 11:42, Ray Kinsella: >>>>> On 17/04/2020 10:31, Bruce Richardson wrote: >>>>>> On Fri, Apr 17, 2020 at 08:24:30AM +0100, Ray Kinsella wrote: >>>>>>> On 16/04/2020 11:01, Thomas Monjalon wrote: >>>>>>>> 16/04/2020 11:51, Bruce Richardson: >>>>>>>>> On Wed, Apr 15, 2020 at 06:24:19PM +0100, Trahe, Fiona wrote: >>>>>>>>>> 5a. If in 20.05 we add a version of a fn which breaks ABI 20.0, what >>>>>>>>>> should the name of the >>> original function be? fn_v20, or fn_v20.0 >>>>>>>>> >>>>>>>>> In technical terms it really doesn't matter, it's just a name that >>>>>>>>> will be >>>>>>>>> looked up in a table. I don't think we strictly enforce the naming, so >>>>>>>>> whatever is clearest is best. I'd suggest the former. >>>>>>>> >>>>>>>> Each release can have a new ABI. >>>>>>> >>>>>>> How many ABI's do we want to support? >>>>>>> >>>>>> It's not how many we want to support, but for me it's a matter of how >>>>>> many >>>>>> do we need to support. If an API is part of the stable set, it can't just >>>>>> drop to being experimental for one or two releases - it's always stable >>>>>> until deprecated. We also shouldn't have a situation where release 20.08 >>>>>> is >>>>>> ABI compatible with 19.11 but not 20.02 and 20.05. >>>>> >>>>> True. Let me say it differently. >>>>> >>>>> Our only commitment is to support v20 - 19.11 >>>>> However you are correct, if something gets committed as v21 in 20.02, in >>>>> practise should also be >>> there in 20.05+ also. >>>>> Because if it is committed as v21 and not as experimental, it should not >>>>> be changing once >>> committed. >>>>> >>>>> In answering Thomas, >>>>> I was more commenting on the proliferation of ABI numbers & symbols we >>>>> need to track in the >>> build. >>>>> With v20, v21 & Experimental we need to keep track of 3. >>>>> If we start allowing quarterly builds to have managed ABI's, it will get >>>>> confusing. >>>> >>>> I don't remember why we are using intermediate ABI versions >>>> between v20 and v21. >>>> If we can use v21 for new ABI and make sure compatibility is maintained >>>> between all versions from 19.11 to 20.08, I'm fine. >> [Fiona] Here's a hypothetical case, but it illustrates why I don't think >> there >> should be an expectation to maintain ABI compatibility here. >> Example: in 20.05 add a new info_get_v21() which includes ChaChaPoly. >> In 20.08 add another new algorithm. info_get_v21() return now includes this. >> info_get_v21() will become stable in 20.11 and compatibility must be >> maintained from then on. >> In the meantime, the fn is not experimental - that wouldn't be appropriate >> as it was a stable API. >> But an app either wants stability and so should build against 19.11, or if >> prepared to move up to >> one non-stable-ABI quarterly release should be willing to rebuild for the >> next non-stable-ABI quarterly >> release. >> I think it's an unnecessary burden to require ABI compatibility across >> quarterly releases. >> And if required could end up with the version tracking hassle Ray referred >> to above with fn versions >> of 20.0.1, 20.0.2, 20.0.3, v21, and potentially several versions of same fn. >> >
