From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org X-Spam-Level: X-Spam-Status: No, score=-3.6 required=3.0 tests=DKIM_INVALID,DKIM_SIGNED, HEADER_FROM_DIFFERENT_DOMAINS,MAILING_LIST_MULTI,SIGNED_OFF_BY,SPF_HELO_NONE, SPF_PASS autolearn=no autolearn_force=no version=3.4.0 Received: from mail.kernel.org (mail.kernel.org [198.145.29.99]) by smtp.lore.kernel.org (Postfix) with ESMTP id ED94CC33CB6 for ; Thu, 16 Jan 2020 14:38:15 +0000 (UTC) Received: from dpdk.org (dpdk.org [92.243.14.124]) by mail.kernel.org (Postfix) with ESMTP id 8D29F207FF for ; Thu, 16 Jan 2020 14:38:14 +0000 (UTC) Authentication-Results: mail.kernel.org; dkim=fail reason="signature verification failed" (1024-bit key) header.d=monjalon.net header.i=@monjalon.net header.b="QnmdC4Fw"; dkim=fail reason="signature verification failed" (2048-bit key) header.d=messagingengine.com header.i=@messagingengine.com header.b="Nasmvlar" DMARC-Filter: OpenDMARC Filter v1.3.2 mail.kernel.org 8D29F207FF Authentication-Results: mail.kernel.org; dmarc=none (p=none dis=none) header.from=monjalon.net Authentication-Results: mail.kernel.org; spf=pass smtp.mailfrom=dev-bounces@dpdk.org Received: from [92.243.14.124] (localhost [127.0.0.1]) by dpdk.org (Postfix) with ESMTP id F23C91D579; Thu, 16 Jan 2020 15:38:13 +0100 (CET) Received: from new2-smtp.messagingengine.com (new2-smtp.messagingengine.com [66.111.4.224]) by dpdk.org (Postfix) with ESMTP id DC4D51D576; Thu, 16 Jan 2020 15:38:12 +0100 (CET) Received: from compute1.internal (compute1.nyi.internal [10.202.2.41]) by mailnew.nyi.internal (Postfix) with ESMTP id 2FD946E19; Thu, 16 Jan 2020 09:38:12 -0500 (EST) Received: from mailfrontend2 ([10.202.2.163]) by compute1.internal (MEProxy); Thu, 16 Jan 2020 09:38:12 -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=HLZIrpCB+TFq1YyC0kt4qZbAbWvlo3sc6VCODeiEUWg=; b=QnmdC4FwAl6L epJN5ehoJvyslw+jealtDgtiXZVMeJDRGG4EX5RG+usQ92vLY3/EhxP/kOeuws1m U/KmI07ptnIhkBUgdewfqFV8FCezQlk9nxfMxeML8FiE2Ln41oH/m0xwb2BOqWDa bD11FappKhlk/khqyiQ8c+CXBs13Rm4= 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=HLZIrpCB+TFq1YyC0kt4qZbAbWvlo3sc6VCODeiEU Wg=; b=NasmvlarH46PwJmvMBt2jag7XHtIEIcPGS1iOEEHIR+8AXuseeXcFzEbR xxSEF+feGhIun7IIpQexksSdpGu1bX4IwUM7DWF2mzXEXXJ9RTt2dMvWzhltNWrl 6S92sk5fW3BsOnP1Edxhsqe51wCveHDYhuM11cxWu4XS5qrUEoYSQlDi1xzuGbzJ COwZgRiNC7+9pqp3GwyW3R9XJk3sm0yXEl+1GKTBtiahcQlBar7CvgQAo3U7gADr zWRgP0Hl9pT9ppb9sXQLmKxoLGRCe7JbQdnsgLvEMadD3JFSEx969MQzjStlHhuY 6COQ0uZM51zxWRc4zanoUgqLEJ0eQ== X-ME-Sender: X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgedugedrtdehgdeihecutefuodetggdotefrodftvf curfhrohhfihhlvgemucfhrghsthforghilhdpqfgfvfdpuffrtefokffrpgfnqfghnecu uegrihhlohhuthemuceftddtnecusecvtfgvtghiphhivghnthhsucdlqddutddtmdenuc fjughrpefhvffufffkjghfggfgtgesthfuredttddtvdenucfhrhhomhepvfhhohhmrghs ucfoohhnjhgrlhhonhcuoehthhhomhgrshesmhhonhhjrghlohhnrdhnvghtqeenucfkph epjeejrddufeegrddvtdefrddukeegnecurfgrrhgrmhepmhgrihhlfhhrohhmpehthhho mhgrshesmhhonhhjrghlohhnrdhnvghtnecuvehluhhsthgvrhfuihiivgeptd 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 57ED230607BE; Thu, 16 Jan 2020 09:38:10 -0500 (EST) From: Thomas Monjalon To: Neil Horman , David Marchand , Ferruh Yigit Cc: Ray Kinsella , Cristian Dumitrescu , dpdk stable , dev , Eelco Chaudron , Kevin Traynor , Ian Stokes , Ilya Maximets , Luca Boccassi Date: Thu, 16 Jan 2020 15:38:08 +0100 Message-ID: <6957820.jRhZ6ZUK3Y@xps> In-Reply-To: References: <20191217130742.165886.15691.stgit@netdev64> <20200116115458.GB3282@hmswarspite.think-freely.org> MIME-Version: 1.0 Content-Transfer-Encoding: 7Bit Content-Type: text/plain; charset="us-ascii" Subject: Re: [dpdk-dev] [dpdk-stable] [PATCH] meter: move RFC4115 trTCM APIs as none experimental 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" 16/01/2020 13:42, Ferruh Yigit: > On 1/16/2020 11:54 AM, Neil Horman wrote: > > On Thu, Jan 16, 2020 at 12:25:06PM +0100, David Marchand wrote: > >> On Tue, Dec 17, 2019 at 2:08 PM Eelco Chaudron wrote: > >>> > >>> Moved RFC4115 APIs to none experimental as they have been there > >>> since 19.02. Also, these APIs are the same as the none RFC4115 APIs. > >>> > >>> Signed-off-by: Eelco Chaudron > >> > >> There is a discussion on the OVS ml at the moment to get these symbols > >> in the stable ABI for 19.11. > >> I want to understand how this would be done. > >> > >> - I take this patch in 20.02, these symbols are added in the 20.0.1 ABI. > >> On the other hand, the 19.11 release maintains the 20.0 ABI. > >> > >> Does it mean the backport adds these symbols with the 20.0 version in > >> the 19.11 branch? > >> Or is 20.0.1 version acceptable / a thing we want? We cannot have the symbol with different versions in different releases, otherwise the compatibility is broken when upgrading. So we have no choice, the symbol must have version 20.0.1 in release 19.11.1, as in release 20.02. > >> - These symbol already existed in the 20.0 ABI, versioned as EXPERIMENTAL. > >> We can go and remove these entries since we are not bound to preserve > >> the experimental APIs. > >> But, on the other hand, nothing should prevent us from keeping some > >> aliases so that the symbols versioned EXPERIMENTAL are still available > >> to existing users. > >> > > I would say that choice is up to you. If you want to alias them to be nice to > > prior users, thats fine by me. But experimental means experimental, and so users > > have to be prepared to rebuild when things change, even if that change is > > changing the version from experimental to a concrete version. > > > > I would prefer to keep the alias and don't break the existing users, specially > for the case experimental API is becoming mature without change. I agree, it's cool to be nice :)