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