From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from dpdk.org (dpdk.org [92.243.14.124]) by inbox.dpdk.org (Postfix) with ESMTP id 62F84A058A; Fri, 17 Apr 2020 12:17:39 +0200 (CEST) Received: from [92.243.14.124] (localhost [127.0.0.1]) by dpdk.org (Postfix) with ESMTP id 117C61D711; Fri, 17 Apr 2020 12:17:39 +0200 (CEST) Received: from out4-smtp.messagingengine.com (out4-smtp.messagingengine.com [66.111.4.28]) by dpdk.org (Postfix) with ESMTP id 74B731D6CF for ; Fri, 17 Apr 2020 12:17:37 +0200 (CEST) Received: from compute7.internal (compute7.nyi.internal [10.202.2.47]) by mailout.nyi.internal (Postfix) with ESMTP id 2766E5C0289; Fri, 17 Apr 2020 06:17:36 -0400 (EDT) Received: from mailfrontend1 ([10.202.2.162]) by compute7.internal (MEProxy); Fri, 17 Apr 2020 06:17:36 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=monjalon.net; h= from:to:cc:subject:date:message-id:in-reply-to:references :mime-version:content-transfer-encoding:content-type; s=mesmtp; bh=m5YJ0bhUK+eVP2L7Qyg7vbS8Mh1gR6Kowv01g2L0EXM=; b=MIFRNRCEoIE/ y2IR9KPLvMhQrC/XANVHfAvp+ldODaIeSrlPGQC8jjel6WFnno2bR51oyglPRAC4 7fn7w8F/PKsMM9KXRT4XQtyn+8f3dhYAYuh6A7t69Q4wjabZb0CYy+Hu8vlTeXoC VZj40diJyeI9LU7CaurnwBNU/YtuIdk= DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= messagingengine.com; h=cc:content-transfer-encoding:content-type :date:from:in-reply-to:message-id:mime-version:references :subject:to:x-me-proxy:x-me-proxy:x-me-sender:x-me-sender :x-sasl-enc; s=fm2; bh=m5YJ0bhUK+eVP2L7Qyg7vbS8Mh1gR6Kowv01g2L0E XM=; b=pGGUsIftPRso7Fkbyk/u56IIpGljYr2diZmTdGLmCXKxtFSwFyOkQGHWK 6FGAAJJc9kccq22Xc6uxtAnQtd4/KxGOKD6aFzs1H9vJwtwCxQu9LKfyVJqHJpRD L6A0WNPIU5c3OlvAahIryCDic9jIg9t5bel0+uLpl61ZlWevLjsUjhaXjH0keSnA ucXxQhFUrbAHLE+spxu1IEKbPSH12MUFAFLQvMl/Y/6MK29QKv2ZI6T2mXGooncV eCQmpGZ4b3dbuQ7vSS0WFEBKbowgOVuZ5rCi+35gkzRx0354wbFD7gSrGig3HqMQ thj+55IxJcG8hN90U98DOQ9PQy34w== X-ME-Sender: X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgeduhedrfeejgddvhecutefuodetggdotefrodftvf curfhrohhfihhlvgemucfhrghsthforghilhdpqfgfvfdpuffrtefokffrpgfnqfghnecu uegrihhlohhuthemuceftddtnecusecvtfgvtghiphhivghnthhsucdlqddutddtmdenuc fjughrpefhvffufffkjghfggfgtgesthfuredttddtvdenucfhrhhomhepvfhhohhmrghs ucfoohhnjhgrlhhonhcuoehthhhomhgrshesmhhonhhjrghlohhnrdhnvghtqeenucfkph epjeejrddufeegrddvtdefrddukeegnecuvehluhhsthgvrhfuihiivgeptdenucfrrghr rghmpehmrghilhhfrhhomhepthhhohhmrghssehmohhnjhgrlhhonhdrnhgvth X-ME-Proxy: Received: from xps.localnet (184.203.134.77.rev.sfr.net [77.134.203.184]) by mail.messagingengine.com (Postfix) with ESMTPA id 87F303280065; Fri, 17 Apr 2020 06:17:34 -0400 (EDT) From: Thomas Monjalon To: Bruce Richardson , Ray Kinsella Cc: "Trahe, Fiona" , "dev@dpdk.org" , "Kusztal, ArkadiuszX" , Neil Horman , Luca Boccassi , Kevin Traynor , "Yigit, Ferruh" Date: Fri, 17 Apr 2020 12:17:33 +0200 Message-ID: <3220159.VZ3vTMCxA0@thomas> In-Reply-To: <147b0819-6dba-7992-488c-2088d0baae75@ashroe.eu> References: <20200318204136.10508-1-arkadiuszx.kusztal@intel.com> <20200417093129.GA1701@bricha3-MOBL.ger.corp.intel.com> <147b0819-6dba-7992-488c-2088d0baae75@ashroe.eu> MIME-Version: 1.0 Content-Transfer-Encoding: 7Bit Content-Type: text/plain; charset="us-ascii" Subject: Re: [dpdk-dev] [PATCH] cryptodev: version rte_cryptodev_info_get function X-BeenThere: dev@dpdk.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: DPDK patches and discussions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: dev-bounces@dpdk.org Sender: "dev" 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.