From patchwork Mon Nov 6 11:28:06 2017 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Patchwork-Submitter: Bruce Richardson X-Patchwork-Id: 31205 Return-Path: X-Original-To: patchwork@dpdk.org Delivered-To: patchwork@dpdk.org Received: from [92.243.14.124] (localhost [127.0.0.1]) by dpdk.org (Postfix) with ESMTP id 6C1DB1B2AE; Mon, 6 Nov 2017 12:49:11 +0100 (CET) Received: from mga04.intel.com (mga04.intel.com [192.55.52.120]) by dpdk.org (Postfix) with ESMTP id 1C17D1B2A4 for ; Mon, 6 Nov 2017 12:49:08 +0100 (CET) Received: from fmsmga006.fm.intel.com ([10.253.24.20]) by fmsmga104.fm.intel.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 06 Nov 2017 03:49:07 -0800 X-ExtLoop1: 1 X-IronPort-AV: E=Sophos;i="5.44,352,1505804400"; d="scan'208";a="172513523" Received: from silpixa00399126.ir.intel.com (HELO silpixa00399126.ger.corp.intel.com) ([10.237.223.223]) by fmsmga006.fm.intel.com with ESMTP; 06 Nov 2017 03:49:07 -0800 From: Bruce Richardson To: john.mcnamara@intel.com Cc: dev@dpdk.org, Bruce Richardson Date: Mon, 6 Nov 2017 11:28:06 +0000 Message-Id: <20171106112806.104289-1-bruce.richardson@intel.com> X-Mailer: git-send-email 2.13.6 Subject: [dpdk-dev] [PATCH] doc: update ABI/API policy 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" Following agreement at the DPDK Technical Board meeting of 2017-10-13 [1], update the documentation with the ABI/API policy changes. [1] http://dpdk.org/ml/archives/dev/2017-October/079961.html Signed-off-by: Bruce Richardson Acked-by: John McNamara Acked-by: Yuanhan Liu Acked-by: Kevin Traynor Acked-by: Thomas Monjalon --- doc/guides/contributing/versioning.rst | 19 ++++++++++++++++++- 1 file changed, 18 insertions(+), 1 deletion(-) diff --git a/doc/guides/contributing/versioning.rst b/doc/guides/contributing/versioning.rst index 8d0fdb777..a1d8492a1 100644 --- a/doc/guides/contributing/versioning.rst +++ b/doc/guides/contributing/versioning.rst @@ -13,7 +13,9 @@ General Guidelines ------------------ #. Whenever possible, ABI should be preserved -#. The libraries marked in experimental state may change without constraint. +#. Libraries or APIs marked in ``experimental`` state may change without constraint. +#. New API will be marked as ``experimental`` for at least one release to allow + any issues found by users of the new API to be fixed quickly #. The addition of symbols is generally not problematic #. The modification of symbols can generally be managed with versioning #. The removal of symbols generally is an ABI break and requires bumping of the @@ -41,6 +43,13 @@ ABI versions are set at the time of major release labeling, and the ABI may change multiple times, without warning, between the last release label and the HEAD label of the git tree. +APIs marked as ``experimental`` are not considered part of the ABI and may +change without warning at any time. Since changes to APIs are most likely +immediately after their introduction, as users begin to take advantage of +those new API and start finding issues with them, new DPDK APIs will be +automatically marked as ``experimental`` to allow for a period of stabilization +before they become part of a tracked ABI. + ABI versions, once released, are available until such time as their deprecation has been noted in the Release Notes for at least one major release cycle. For example consider the case where the ABI for DPDK 2.0 has been @@ -58,6 +67,14 @@ being provided. The requirements for doing so are: #. At least 3 acknowledgments of the need to do so must be made on the dpdk.org mailing list. + - The acknowledgment of the maintainer of the component is mandatory, or if + no maintainer is available for the component, the tree/sub-tree maintainer + for that component must be acknowledge the ABI change instead. + + - It is also recommended that acknowledgments from different "areas of + interest" be sought for each deprecation, for example: from NIC vendors, + CPU vendors, end-users, etc. + #. The changes (including an alternative map file) must be gated with the ``RTE_NEXT_ABI`` option, and provided with a deprecation notice at the same time.