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 64B40A051A for ; Fri, 17 Jan 2020 09:28:04 +0100 (CET) Received: from [92.243.14.124] (localhost [127.0.0.1]) by dpdk.org (Postfix) with ESMTP id 4324F1D17F; Fri, 17 Jan 2020 09:28:04 +0100 (CET) Received: from us-smtp-1.mimecast.com (us-smtp-delivery-1.mimecast.com [205.139.110.120]) by dpdk.org (Postfix) with ESMTP id 4EB3D1D17E for ; Fri, 17 Jan 2020 09:28:02 +0100 (CET) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=redhat.com; s=mimecast20190719; t=1579249681; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:cc:mime-version:mime-version:content-type:content-type: content-transfer-encoding:content-transfer-encoding: in-reply-to:in-reply-to:references:references; bh=+E5ouEzdZL2C4KkCWvwK/sPHuLTmJ2YyLHFNazgxYqQ=; b=IBNRbw9IOJIs8WSKjtzzvMdCt/q+XI/YcKB4X9DlymHj+nznQ0CZRHVpZYStXSWn0EtmT2 FregbmulQa9vMcyukzT2PgUoKC9iDmEpK+JPn7IlywIatBAz4HR1uaTrnHoAHe+XLAAh29 5Z8oLLGNmOcumdpADjKHHyXiRoyceqE= Received: from mail-ua1-f69.google.com (mail-ua1-f69.google.com [209.85.222.69]) (Using TLS) by relay.mimecast.com with ESMTP id us-mta-396-Z7pkScMBPgeAAV9JCKkyVg-1; Fri, 17 Jan 2020 03:27:57 -0500 Received: by mail-ua1-f69.google.com with SMTP id f15so3771016uap.4 for ; Fri, 17 Jan 2020 00:27:57 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=1gN21rTrG+G1wXqM5Yio3TNDnO3RMD2GivIhuCQypx0=; b=JPZnt3AWWtAiZFsZnO2cCl5XJ6312JdsIwyaPqjv7obPjDTK147mZ2vcBwrXiEM4ai MNogDrFN0Hpku7cxqv5YN5Gt5iIYi26LNC+WxIyhAad8/feaNLwFJyN3BOjyJo8qRl+A tjyaGslQ0QWCY+B1Ahv7oqKnWhsxNoDXu9ERGt3BdqAy2lsjPOS1Nl5FN+BM9KbuDo+q cu1R65RAA0KY5hSCnVqFyLdE1AJr+VO3VemNC/HDBccS7fk94B8x+4rs5v/uqMHObkGx 8kbewTDrUAZilzgUabLYF9cVoYrOBh36U7BysUrS4h6FcNMWc8m5irT8xY/YAizYfjvR hf+w== X-Gm-Message-State: APjAAAX6FzNTW80u0VdZrYr88+PD0Qazcz0AGkfAyOfxi7ozNeSK0CGF MJ0Z4s9QILICBaSE0ZIhz+mtiSaqbYhZLSc2LUkMbTp7EeHGdv0oWEmk58Oyk+uSwpzaUHHXO+j n4Qk+C6b2TJPpr4L2bOF2XXE= X-Received: by 2002:a67:e342:: with SMTP id s2mr4062007vsm.198.1579249676697; Fri, 17 Jan 2020 00:27:56 -0800 (PST) X-Google-Smtp-Source: APXvYqxDP6iEu/kg5285Ax7lZHw9cJq/XBbCK8PhmF1EpxlMMCPkCohheVWpjZSh030A0YVMn9RKetu0XKxKCEqvaCg= X-Received: by 2002:a67:e342:: with SMTP id s2mr4061998vsm.198.1579249676415; Fri, 17 Jan 2020 00:27:56 -0800 (PST) MIME-Version: 1.0 References: <20191217130742.165886.15691.stgit@netdev64> <20200116115458.GB3282@hmswarspite.think-freely.org> <6957820.jRhZ6ZUK3Y@xps> In-Reply-To: <6957820.jRhZ6ZUK3Y@xps> From: David Marchand Date: Fri, 17 Jan 2020 09:27:45 +0100 Message-ID: To: Thomas Monjalon , Luca Boccassi Cc: Neil Horman , Ferruh Yigit , Ray Kinsella , Cristian Dumitrescu , dpdk stable , dev , Eelco Chaudron , Kevin Traynor , Ian Stokes , Ilya Maximets X-MC-Unique: Z7pkScMBPgeAAV9JCKkyVg-1 X-Mimecast-Spam-Score: 0 X-Mimecast-Originator: redhat.com Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Subject: Re: [dpdk-stable] [PATCH] meter: move RFC4115 trTCM APIs as none experimental X-BeenThere: stable@dpdk.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: patches for DPDK stable branches List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: stable-bounces@dpdk.org Sender: "stable" On Thu, Jan 16, 2020 at 3:38 PM Thomas Monjalon wrote= : > > 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 symbo= ls > > >> 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 i= n > > >> 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. Indeed, good point. > > >> - These symbol already existed in the 20.0 ABI, versioned as EXPERIM= ENTAL. > > >> We can go and remove these entries since we are not bound to preserv= e > > >> the experimental APIs. > > >> But, on the other hand, nothing should prevent us from keeping some > > >> aliases so that the symbols versioned EXPERIMENTAL are still availab= le > > >> to existing users. > > >> > > > I would say that choice is up to you. If you want to alias them to b= e nice to > > > prior users, thats fine by me. But experimental means experimental, a= nd so users > > > have to be prepared to rebuild when things change, even if that chang= e is > > > changing the version from experimental to a concrete version. > > > > > > > I would prefer to keep the alias and don't break the existing users, sp= ecially > > for the case experimental API is becoming mature without change. > > I agree, it's cool to be nice :) Luca, opinion? --=20 David Marchand