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=-0.8 required=3.0 tests=DKIM_SIGNED,DKIM_VALID, DKIM_VALID_AU,HEADER_FROM_DIFFERENT_DOMAINS,MAILING_LIST_MULTI,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 B7457C5DF63 for ; Wed, 6 Nov 2019 21:08:09 +0000 (UTC) Received: from dpdk.org (dpdk.org [92.243.14.124]) by mail.kernel.org (Postfix) with ESMTP id EF99A20663 for ; Wed, 6 Nov 2019 21:08:08 +0000 (UTC) Authentication-Results: mail.kernel.org; dkim=pass (1024-bit key) header.d=monjalon.net header.i=@monjalon.net header.b="Oqddir1P"; dkim=pass (2048-bit key) header.d=messagingengine.com header.i=@messagingengine.com header.b="iE4ddZfQ" DMARC-Filter: OpenDMARC Filter v1.3.2 mail.kernel.org EF99A20663 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 D56BC1E93A; Wed, 6 Nov 2019 22:08:07 +0100 (CET) Received: from new3-smtp.messagingengine.com (new3-smtp.messagingengine.com [66.111.4.229]) by dpdk.org (Postfix) with ESMTP id A745E1E935 for ; Wed, 6 Nov 2019 22:08:06 +0100 (CET) Received: from compute1.internal (compute1.nyi.internal [10.202.2.41]) by mailnew.nyi.internal (Postfix) with ESMTP id 1E0356C82; Wed, 6 Nov 2019 16:08:06 -0500 (EST) Received: from mailfrontend2 ([10.202.2.163]) by compute1.internal (MEProxy); Wed, 06 Nov 2019 16:08:06 -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=jzElBcGdT9rqMyWI1Wn0nI3yrhZ1pH1QAmcsp5Ysovk=; b=Oqddir1POxjR H4UaQOMO7WgFLtbaUl1v5zr+uXw1RIiQy+YOSsfSjzOgZv1gtFfA+LV8JvEwuPNO NFuhgZYwCB9zhaGCULrw1sIb+Lf0Ci5DeXILsLHIbBmZJPduB/VcuRrc2ElNd7Jk so7MvI2KwVVfh/+RLbAwLW/Ukik1u3E= 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=jzElBcGdT9rqMyWI1Wn0nI3yrhZ1pH1QAmcsp5Yso vk=; b=iE4ddZfQka+5JGK116B6kh38KUKQGBuIHTAV3Tk5WRCxRBwhot/W9QDsq ySGY3CKQocXtDwGafLD9nq3rDobB+EZ/2lmJVlBliTohQajZoUiq2fhULpfbSi5o Er7yHtXh+tBqqsQ+k2ZV8PQOXqWadr7jVKglNdjCbA+1M3msTPdgwkHPkNOj/ZsZ CkZSFMI49moJ+z1q+NukyZ0yr4Cdm695aGIez/BmPuW7QWdcNQjrPFHfSnuwTJY4 OH5W/TvonGGsXnb6eAjJy1BmbRQqkrqM01lXgbdj5JANm6bxp0OtOStbLEC/SQ8e U1baSEuoNrDqUz8hUF9KT6Td0ynqQ== X-ME-Sender: X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgedufedruddujedgudegjecutefuodetggdotefrod ftvfcurfhrohhfihhlvgemucfhrghsthforghilhdpqfgfvfdpuffrtefokffrpgfnqfgh necuuegrihhlohhuthemuceftddtnecunecujfgurhephffvufffkfgjfhgggfgtsehtuf ertddttddvnecuhfhrohhmpefvhhhomhgrshcuofhonhhjrghlohhnuceothhhohhmrghs sehmohhnjhgrlhhonhdrnhgvtheqnecukfhppeejjedrudefgedrvddtfedrudekgeenuc frrghrrghmpehmrghilhhfrhhomhepthhhohhmrghssehmohhnjhgrlhhonhdrnhgvthen ucevlhhushhtvghrufhiiigvpedt 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 A63D9306005C; Wed, 6 Nov 2019 16:08:03 -0500 (EST) From: Thomas Monjalon To: Ray Kinsella Cc: dev@dpdk.org, stephen@networkplumber.org, bruce.richardson@intel.com, ferruh.yigit@intel.com, konstantin.ananyev@intel.com, jerinj@marvell.com, olivier.matz@6wind.com, nhorman@tuxdriver.com, maxime.coquelin@redhat.com, john.mcnamara@intel.com, marko.kovacevic@intel.com, hemant.agrawal@nxp.com, ktraynor@redhat.com, aconole@redhat.com Date: Wed, 06 Nov 2019 22:07:56 +0100 Message-ID: <2076195.DiE3OUsusb@xps> In-Reply-To: <070cba22-4e70-032a-cf34-16015b916e75@ashroe.eu> References: <1572967458-16487-1-git-send-email-mdr@ashroe.eu> <2325188.Q6BSOo8498@xps> <070cba22-4e70-032a-cf34-16015b916e75@ashroe.eu> MIME-Version: 1.0 Content-Transfer-Encoding: 7Bit Content-Type: text/plain; charset="us-ascii" Subject: Re: [dpdk-dev] [PATCH v8 2/4] doc: changes to abi policy introducing major abi versions 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" Hi, Please find the techboard comments below. 06/11/2019 10:22, Ray Kinsella: > On 06/11/2019 09:06, Thomas Monjalon wrote: > > 06/11/2019 09:49, Ray Kinsella: > >> On 06/11/2019 00:11, Thomas Monjalon wrote: > >>> 05/11/2019 16:24, Ray Kinsella: > >>>> +#. Major ABI versions are declared every **year** and are then supported for one > >>>> + year, typically aligned with the :ref:`LTS release `. > >>> > >>> As discussed earlier, a major ABI version can be declared less often > >>> than one year in the future. > >>> An ABI is supported more than one year, because of the LTS branches. > >>> That's why I propose to replace with this sentence: > >>> " > >>> Major ABI versions are declared regularly and are then supported for > >>> at least one year, typically aligned with the :ref:`LTS release `. > >>> " > >> > >> So look, this one was a decision of the technical board. > > > > The techboard didn't decide to change the ABI every year. > > We decided to review the duration after the first year, with a plan to extend. > > > >> My position is still what was agreed was, "declared every year, and supported for one year". > >> I like it, it's crystal clear what is the policy, until we change the policy. > > > > I think it gives a wrong message. > > > >> That said, I can make the change no problem, but I need some others to chime in to ok it. > >> Perhaps at the head of the Techboard today? > > > > Yes I add it to the techboard meeting. The techboard propose other rewords: "supported" may be replaced with "compatibility is enforced" "every year" may be replaced with "no more frequently than every year" "declared" may be replaced with "could be declared" I think you got the idea. Please adjust wording to something more accurate. ### > >>>> +A major ABI version is declared every year, aligned with that year's LTS > >>>> +release, e.g. v19.11. This ABI version is then supported for one year by all > >>>> +subsequent releases within that time period, until the next LTS release, e.g. > >>>> +v20.11. > >>> > >>> Let's reword like this: > >>> " > >>> A new major ABI version can be declared when a new LTS branch is started, It has been suggested to replace "can" with "may". > >>> e.g. ABI 19 for DPDK 19.11.0. > >>> This major ABI version is then supported until the next one, > >>> e.g. ABI 20 for DPDK 20.11.0. > >>> All ABI changes must be detailed in the release notes. > >>> " My reword is wrong because ABI versions should be 20 and 21 respectively. > >> This is more ambiguous, although what I said above stands. > > > > What you said is wrong because of 2 reasons: > > - it is not always one year for an major ABI > > Well that is a point of disagreement. The techboard agreed to remove "every year". > > > - it is always longer because of LTS branch > > Well I was pretty careful to qualify the ABI policy applies to releases over the year. > To distinguish it from LTS branch. As above, we may replace "ABI is supported" with "ABI compatibility is enforced". > >> If there is general agreement with changing this part of the policy, I am ok to make > >> the change. > > > > Yes let's review with the techboard. Please try to reflect techboard comments while keeping something understandable :) ### > >>>> + ABI breakages due to changes such as reorganizing public > >>>> + structure fields for aesthetic or readability purposes should be avoided. > >>> > >>> Why it should be avoided? > >>> If the ABI is broken anyway, I don't see any reason to not break it more. > >> > >> This is text from the original ABI Policy - I think the general sentiment still stands. > >> Just because you have an ABI Breakage window doesn't mean you should feel free to break > >> the ABI. The 3 ACKs required from Technical Board member to change the ABI, are another > >> reflection of this. > >> > >> As a general rule. > >> Unnecessary changes should still be avoided, to reduce ABI churn between ABI versions. > > > > I agree we must avoid unnecessary API changes because it requires apps to adapt. > > But if the change is only ABI, and we are in an ABI-change window, > > I don't see any issue The techboard agrees that the ABI changes are unlimited but API changes must be avoided. It is suggested to replace "ABI" with "API". I think this reword is better: " API changes such as reorganizing public structure fields for aesthetic or readability purposes should be avoided. " ### > >>>> +Libraries marked as ``experimental`` are entirely not considered part of an ABI > >>>> +version, and may change without warning at any time. Experimental libraries > >>>> +always have a major version of ``0`` to indicate they exist outside of > >>>> +ABI Versioning, with the minor version incremented with each ABI change > >>>> +to library. > >>> > >>> It means not all libraries will have the same ABI version. > >>> It is contrary of "ABI version is managed at a project level", > >>> and I don't see a real benefit of a different version number. > >> > >> There is a benefit, major version 0 is a very clear indication that > >> the library exists outside of ABI management. > >> A library isn't in the ABI, until it is in the ABI - an then it gets > >> added to the major version number. > >> > >>> Anyway, some experimental functions can live inside a library > >>> with a stable ABI version number > >> > >> True, but if an entire library is experimental - let's be crystal > >> clear about that. > > > > I would like to see what others think. The techboard decided to keep this policy: .0 for pure experimental libs.