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 <fiona.tr...@intel.com> >> Sent: Friday, April 17, 2020 12:47 PM >> To: Ray Kinsella <m...@ashroe.eu>; Thomas Monjalon <tho...@monjalon.net>; >> Richardson, Bruce >> <bruce.richard...@intel.com> >> Cc: dev@dpdk.org; Kusztal, ArkadiuszX <arkadiuszx.kusz...@intel.com>; Neil >> Horman >> <nhor...@tuxdriver.com>; Luca Boccassi <bl...@debian.org>; Kevin Traynor >> <ktray...@redhat.com>; Yigit, Ferruh <ferruh.yi...@intel.com>; Trahe, Fiona >> <fiona.tr...@intel.com> >> Subject: RE: [dpdk-dev] [PATCH] cryptodev: version rte_cryptodev_info_get >> function >> >> Hi all, >> >>> -----Original Message----- >>> From: Ray Kinsella <m...@ashroe.eu> >>> Sent: Friday, April 17, 2020 11:34 AM >>> To: Thomas Monjalon <tho...@monjalon.net>; Richardson, Bruce >>> <bruce.richard...@intel.com> >>> Cc: Trahe, Fiona <fiona.tr...@intel.com>; dev@dpdk.org; Kusztal, ArkadiuszX >>> <arkadiuszx.kusz...@intel.com>; Neil Horman <nhor...@tuxdriver.com>; Luca >>> Boccassi >>> <bl...@debian.org>; Kevin Traynor <ktray...@redhat.com>; Yigit, Ferruh >>> <ferruh.yi...@intel.com> >>> 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. >> >
