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 5D193A0537; Wed, 5 Feb 2020 12:33:06 +0100 (CET) Received: from [92.243.14.124] (localhost [127.0.0.1]) by dpdk.org (Postfix) with ESMTP id 94D1F1C12C; Wed, 5 Feb 2020 12:33:05 +0100 (CET) Received: from smtp.tuxdriver.com (charlotte.tuxdriver.com [70.61.120.58]) by dpdk.org (Postfix) with ESMTP id 4836E1C121 for ; Wed, 5 Feb 2020 12:33:04 +0100 (CET) Received: from [107.15.85.130] (helo=localhost) by smtp.tuxdriver.com with esmtpsa (TLSv1:AES256-SHA:256) (Exim 4.63) (envelope-from ) id 1izIvK-000557-PA; Wed, 05 Feb 2020 06:32:53 -0500 Date: Wed, 5 Feb 2020 06:32:45 -0500 From: Neil Horman To: Luca Boccassi Cc: Ferruh Yigit , Cristian Dumitrescu , Eelco Chaudron , dev@dpdk.org, Thomas Monjalon , David Marchand , Bruce Richardson , Ian Stokes Message-ID: <20200205113245.GA17468@hmswarspite.think-freely.org> References: <20200129122953.2016199-1-ferruh.yigit@intel.com> <20200202185334.GA6783@localhost.localdomain> <7beadbbd-bf0d-e545-d9bb-0e3ae8228b71@intel.com> <20200204120230.GA13754@hmswarspite.think-freely.org> <8eaaec5dedcfcf09ae69b15cc80ac1ff1a1f4a30.camel@debian.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <8eaaec5dedcfcf09ae69b15cc80ac1ff1a1f4a30.camel@debian.org> X-Spam-Score: -2.9 (--) X-Spam-Status: No Subject: Re: [dpdk-dev] [RFC] meter: fix ABI break due to experimental tag removal 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" On Wed, Feb 05, 2020 at 11:04:29AM +0100, Luca Boccassi wrote: > On Tue, 2020-02-04 at 07:02 -0500, Neil Horman wrote: > > > But if we can do the versioning in the master, LTS can backport it > > > and can have > > > mature version of that API in LTS without breaking the existing > > > users. > > > > > > > But why bother? The only thing you've changed is the version > > tagging. Its ok > > to leave that alone in LTS, you just cant change it. > > > > Thats part of the burden of an LTS release, it will have some drift > > from the > > upstream head, because you have to keep things stable. So you > > stabilize the > > upstream ABI version for this API and just never backport it to the > > current LTS > > release. > > Hi, > > A customer (OVS) explicitly and specifically requested backporting the > symbol change to 19.11, as they don't want to enable experimental APIs > in their releases. I replied that it would only be acceptable with > aliasing to keep compatibility, and Ferruh very kindly did the work to > implement that. > but, thats part of the agreement, no? You can't always have new features and stability at the same time. I get that this is an odd corner case, because strictly speaking you could waive the ABI change that libabigail is reporting, and most application users (like OVS) could get away with it, because their application does all the right things to make it ok, but I don't think you can make a decsion like this for all users based on the request of a single user. It seems like the right thing is for OVS to augment their build time configuration to allow developers to select the ability to use experimental apis at compile time, and then the decision is placed in the hands of end users. Neil > -- > Kind regards, > Luca Boccassi >