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 4E659A04FA; Wed, 5 Feb 2020 16:43:57 +0100 (CET) Received: from [92.243.14.124] (localhost [127.0.0.1]) by dpdk.org (Postfix) with ESMTP id 2AAE21C2A5; Wed, 5 Feb 2020 16:43:57 +0100 (CET) Received: from relay0101.mxlogin.com (relay0101.mxlogin.com [199.181.239.101]) by dpdk.org (Postfix) with ESMTP id 1C7101C2A0 for ; Wed, 5 Feb 2020 16:43:55 +0100 (CET) Received: from filter004.mxroute.com ([149.28.56.236] 149.28.56.236.vultr.com) (Authenticated sender: mN4UYu2MZsgR) by relay0101.mxlogin.com (ZoneMTA) with ESMTPSA id 17016059a9a00035f4.001 for (version=TLSv1/SSLv3 cipher=ECDHE-RSA-AES128-GCM-SHA256); Wed, 05 Feb 2020 15:43:50 +0000 X-Zone-Loop: 701558dffeb0385993f2acee0c3bff6e27d0f0160180 X-Originating-IP: [149.28.56.236] Received: from galaxy.mxroute.com (unknown [23.92.70.113]) by filter004.mxroute.com (Postfix) with ESMTPS id 864463EA00; Wed, 5 Feb 2020 15:43:49 +0000 (UTC) Received: from irdmzpr02-ext.ir.intel.com ([192.198.151.37] helo=localhost) by galaxy.mxroute.com with esmtpsa (TLSv1.2:ECDHE-RSA-AES128-GCM-SHA256:128) (Exim 4.91) (envelope-from ) id 1izMWl-0003du-2f; Wed, 05 Feb 2020 10:23:43 -0500 From: Ray Kinsella To: dev@dpdk.org Cc: john.mcnamara@intel.com, nhorman@tuxdriver.com, ferruh.yigit@intel.com, marko.kovacevic@intel.co, Ray Kinsella Date: Wed, 5 Feb 2020 15:43:41 +0000 Message-Id: <1580917421-2639-1-git-send-email-mdr@ashroe.eu> X-Mailer: git-send-email 2.7.4 In-Reply-To: <1580915872-1686-1-git-send-email-mdr@ashroe.eu> References: <1580915872-1686-1-git-send-email-mdr@ashroe.eu> X-AuthUser: mdr@ashroe.eu Subject: [dpdk-dev] [PATCH v3] doc: alias to experimental tag for stable apis 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" When a maintainer is promoting an API to become part of the next major ABI version by removing the experimental tag, possibly a few releases in advance of the declaration of the next ABI version. The maintainer may choose to offer an alias to the experimental tag, as removing the tag before the declaration of the next major ABI version, would cause an ABI breakage for applications using the API. Signed-off-by: Ray Kinsella --- doc/guides/contributing/abi_policy.rst | 10 ++++++++++ 1 file changed, 10 insertions(+) diff --git a/doc/guides/contributing/abi_policy.rst b/doc/guides/contributing/abi_policy.rst index 05ca959..9a4a102 100644 --- a/doc/guides/contributing/abi_policy.rst +++ b/doc/guides/contributing/abi_policy.rst @@ -159,6 +159,11 @@ The requirements for changing the ABI are: ``experimental``, as described in the section on :ref:`Experimental APIs and Libraries `. + - In situations where an ``experimental`` API has been stable for some time. + When promoting the API to become part of the next ABI version, the + maintainer may choose to provide an alias to the ``experimental`` tag, so + as not to break consuming applications. + #. If a newly proposed API functionally replaces an existing one, when the new API becomes non-experimental, then the old one is marked with ``__rte_deprecated``. @@ -317,6 +322,11 @@ not required. Though, an API should remain in experimental state for at least one release. Thereafter, the normal process of posting patch for review to mailing list can be followed. +After the experimental tag has been formally removed, a tree/sub-tree maintainer +may choose to offer an alias to the experimental tag so as not to break +applications using the API. This alias can then be dropped at the declaration of +next major ABI version. + Libraries ~~~~~~~~~ -- 2.7.4