DPDK patches and discussions
 help / color / mirror / Atom feed
From: Thomas Monjalon <thomas@monjalon.net>
To: Bruce Richardson <bruce.richardson@intel.com>,
	Ray Kinsella <mdr@ashroe.eu>
Cc: "Trahe, Fiona" <fiona.trahe@intel.com>,
	"dev@dpdk.org" <dev@dpdk.org>,
	"Kusztal, ArkadiuszX" <arkadiuszx.kusztal@intel.com>,
	Neil Horman <nhorman@tuxdriver.com>,
	Luca Boccassi <bluca@debian.org>,
	Kevin Traynor <ktraynor@redhat.com>,
	"Yigit, Ferruh" <ferruh.yigit@intel.com>
Subject: Re: [dpdk-dev] [PATCH] cryptodev: version rte_cryptodev_info_get function
Date: Fri, 17 Apr 2020 12:17:33 +0200	[thread overview]
Message-ID: <3220159.VZ3vTMCxA0@thomas> (raw)
In-Reply-To: <147b0819-6dba-7992-488c-2088d0baae75@ashroe.eu>

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.



  reply	other threads:[~2020-04-17 10:17 UTC|newest]

Thread overview: 22+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2020-03-18 20:41 Arek Kusztal
2020-04-14 12:13 ` Akhil Goyal
2020-04-14 13:03   ` Thomas Monjalon
2020-04-14 13:52     ` Trahe, Fiona
2020-04-14 13:54 ` Ray Kinsella
2020-04-14 18:27   ` Trahe, Fiona
2020-04-15 17:24     ` Trahe, Fiona
2020-04-16  9:51       ` Bruce Richardson
2020-04-16 10:01         ` Thomas Monjalon
2020-04-17  7:24           ` Ray Kinsella
2020-04-17  9:31             ` Bruce Richardson
2020-04-17  9:42               ` Ray Kinsella
2020-04-17 10:17                 ` Thomas Monjalon [this message]
2020-04-17 10:33                   ` Ray Kinsella
2020-04-17 11:46                     ` Trahe, Fiona
2020-04-17 16:01                       ` Ray Kinsella
2020-04-20 16:59                       ` Trahe, Fiona
2020-04-20 17:31                         ` Ray Kinsella
2020-04-20 17:37                           ` Thomas Monjalon
2020-04-21  6:01                             ` Ray Kinsella
2020-04-21  9:36                               ` Thomas Monjalon
2020-04-22  8:21                                 ` Ray Kinsella

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=3220159.VZ3vTMCxA0@thomas \
    --to=thomas@monjalon.net \
    --cc=arkadiuszx.kusztal@intel.com \
    --cc=bluca@debian.org \
    --cc=bruce.richardson@intel.com \
    --cc=dev@dpdk.org \
    --cc=ferruh.yigit@intel.com \
    --cc=fiona.trahe@intel.com \
    --cc=ktraynor@redhat.com \
    --cc=mdr@ashroe.eu \
    --cc=nhorman@tuxdriver.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).