From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: <dev-bounces@dpdk.org> Received: from dpdk.org (dpdk.org [92.243.14.124]) by inbox.dpdk.org (Postfix) with ESMTP id 904DBA04F6; Wed, 11 Dec 2019 14:30:02 +0100 (CET) Received: from [92.243.14.124] (localhost [127.0.0.1]) by dpdk.org (Postfix) with ESMTP id 5F9BF2C6A; Wed, 11 Dec 2019 14:30:01 +0100 (CET) Received: from wnew4-smtp.messagingengine.com (wnew4-smtp.messagingengine.com [64.147.123.18]) by dpdk.org (Postfix) with ESMTP id B4C051D9E for <dev@dpdk.org>; Wed, 11 Dec 2019 14:29:59 +0100 (CET) Received: from compute1.internal (compute1.nyi.internal [10.202.2.41]) by mailnew.west.internal (Postfix) with ESMTP id 5D400B0E; Wed, 11 Dec 2019 08:29:57 -0500 (EST) Received: from mailfrontend1 ([10.202.2.162]) by compute1.internal (MEProxy); Wed, 11 Dec 2019 08:29:58 -0500 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=SdV+J1+FWFXX/5c3ucYI8p2AVp3CERVJrPtetC+48rQ=; b=eqKLlKVatwCW xAImnY6txzLGxUIf8mEjg+i+V3wAq/tc9UAIRAHid8hFUjRi6I7FH2b/MoTcQ65G 0avBMXeXyI59Rl88N8QIf77zoXL5rumIi5aWzmWm/yQfAOQSbP8xyGklC+3i4P4Z 5WA81I9aR4TV5rYj00vY2+7m/eINyX4= 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=fm1; bh=SdV+J1+FWFXX/5c3ucYI8p2AVp3CERVJrPtetC+48 rQ=; b=cP7q/s8A1OVN5xgBXQqPcssAnL76t47PxmARLlyrzQ9pSccX7OmEp1UEr olMZUFN7fa2sr7XQg94zkWh7YxV2mRZBRkEDmct6MHyk+SaPpyA6Lq1grzquFlhZ gENQ5JJ7X3u7BbLLoZKkd0uJ4Q++rvGgFwy1A83yu78gvs66lrBOG+KyuFE0Of45 KrQflLvAEzr8pH8xL+4UTB5XhGQcku6Gugc0a0J2TVW60CNPYrTiL2TBEhVocfYN pQ4/zHlAcgWEQzNI3mzSZkI/ZpCfnVAStRgip4Q8Lyqp5ph7/KqU6WNpsPNCbL3j vyJJa14gKoStllzR/WQAtwpFqfK2A== X-ME-Sender: <xms:VO_wXbbeXkxwgcyxAbPckkoksiRBkxiNZYJGR-HXzb9bjPhbSOP4jQ> X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgedufedrudelhedggeekucetufdoteggodetrfdotf fvucfrrhhofhhilhgvmecuhfgrshhtofgrihhlpdfqfgfvpdfurfetoffkrfgpnffqhgen uceurghilhhouhhtmecufedttdenucesvcftvggtihhpihgvnhhtshculddquddttddmne cujfgurhephffvufffkfgjfhgggfgtsehtufertddttddvnecuhfhrohhmpefvhhhomhgr shcuofhonhhjrghlohhnuceothhhohhmrghssehmohhnjhgrlhhonhdrnhgvtheqnecukf hppeejjedrudefgedrvddtfedrudekgeenucfrrghrrghmpehmrghilhhfrhhomhepthhh ohhmrghssehmohhnjhgrlhhonhdrnhgvthenucevlhhushhtvghrufhiiigvpedt X-ME-Proxy: <xmx:VO_wXbKzlWjj47fkkN3jOSVQSszJcyrd559EdqYS0KZg_XFwdojjOw> <xmx:VO_wXfw8vSoOTSF-y59waDYP41upo8Q6ccnRIebGOzxQiIPQnqn4-Q> <xmx:VO_wXX9OGFneCIvmb8CZ-7_EhyqDvX7HJhVHn6L3DXLCSr6qn-o1Pw> <xmx:VO_wXS1z-YxieV5BWraN8KhbwZuX2hsFEaCrhGT3YUveABlaJT3yRC-t9tA> Received: from xps.localnet (184.203.134.77.rev.sfr.net [77.134.203.184]) by mail.messagingengine.com (Postfix) with ESMTPA id AD5168005B; Wed, 11 Dec 2019 08:29:54 -0500 (EST) From: Thomas Monjalon <thomas@monjalon.net> To: Neil Horman <nhorman@tuxdriver.com>, Ferruh Yigit <ferruh.yigit@intel.com> Cc: "Kinsella, Ray" <ray.kinsella@intel.com>, David Marchand <david.marchand@redhat.com>, Luca Boccassi <bluca@debian.org>, Christian Ehrhardt <christian.ehrhardt@canonical.com>, Timothy Redaelli <tredaelli@redhat.com>, Kevin Traynor <ktraynor@redhat.com>, dpdk-dev <dev@dpdk.org>, Bruce Richardson <bruce.richardson@intel.com>, "Laatz, Kevin" <kevin.laatz@intel.com>, Andrew Rybchenko <arybchenko@solarflare.com>, Neil Horman <nhorman@redhat.com> Date: Wed, 11 Dec 2019 14:29:52 +0100 Message-ID: <3607395.IiHQ9X9RKD@xps> In-Reply-To: <20191211131103.GA19627@hmswarspite.think-freely.org> References: <5df1a33b-b338-bde1-6834-e8b5fbe65a04@intel.com> <20191211131103.GA19627@hmswarspite.think-freely.org> MIME-Version: 1.0 Content-Transfer-Encoding: 7Bit Content-Type: text/plain; charset="us-ascii" Subject: Re: [dpdk-dev] How to manage new APIs added after major ABI release? X-BeenThere: dev@dpdk.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: DPDK patches and discussions <dev.dpdk.org> List-Unsubscribe: <https://mails.dpdk.org/options/dev>, <mailto:dev-request@dpdk.org?subject=unsubscribe> List-Archive: <http://mails.dpdk.org/archives/dev/> List-Post: <mailto:dev@dpdk.org> List-Help: <mailto:dev-request@dpdk.org?subject=help> List-Subscribe: <https://mails.dpdk.org/listinfo/dev>, <mailto:dev-request@dpdk.org?subject=subscribe> Errors-To: dev-bounces@dpdk.org Sender: "dev" <dev-bounces@dpdk.org> 11/12/2019 14:11, Neil Horman: > On Tue, Dec 10, 2019 at 11:56:28AM +0000, Ferruh Yigit wrote: > > Hi, > > > > With new process, the major ABI releases will be compatible until it is > > deprecated (until next LTS for now), > > like current ABI version is 20 in DPDK_19.11 and DPDK versions until DPDK_20.11 > > will be ABI compatible with this version. > > > > But if we introduce a new API after major ABI, say in 20.02 release, are we > > allowed to break the ABI for that API before DPDK_20.11? > > > > If we allow it break, following problem will be observed: > > Assume an application using .so.20.1 library, and using the new API introduced > > in 20.02, lets say foo(), > > but when application switches to .so.20.2 (released via DPDK_20.05), application > > will fail because of ABI breakage in foo(). > > > > I think it is fair that application expects forward compatibility in minor > > versions of a shared library. > > Like if application linked against .so.20.2, fair to expect .so.20.3, .so.20.4 > > etc will work fine. I think currently only .so.20.0 is fully forward compatible. > > > > If we all agree on this, we may need to tweak the process a little, but before > > diving into implementation details, I would like to be sure we are in same page. > > > Yes, I agree with the assertion. Once an ABI is fixed, it must be compatible > with all future minor releases subsequent to the fixing of that ABI, until the > next major update. That is to say, once you release ABI_20, all minor updates > 20.01, 20.02, etc must be compatible with ABI_20 until such time as ABI_21 is > released. The question of Ferruh was about compatibility of 20.2 vs 20.1, given both are compatible with 20.0 of course. The question makes sense if a new symbol is added in 20.1. And yes I think the symbol added in a minor version must be kept until the next major ABI.