From patchwork Fri Mar 1 17:32:49 2019 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Patchwork-Submitter: Ferruh Yigit X-Patchwork-Id: 50734 X-Patchwork-Delegate: thomas@monjalon.net 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 2D6184C88; Fri, 1 Mar 2019 18:33:00 +0100 (CET) Received: from mga02.intel.com (mga02.intel.com [134.134.136.20]) by dpdk.org (Postfix) with ESMTP id A7901375B for ; Fri, 1 Mar 2019 18:32:58 +0100 (CET) X-Amp-Result: SKIPPED(no attachment in message) X-Amp-File-Uploaded: False Received: from orsmga002.jf.intel.com ([10.7.209.21]) by orsmga101.jf.intel.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 01 Mar 2019 09:32:58 -0800 X-ExtLoop1: 1 X-IronPort-AV: E=Sophos;i="5.58,428,1544515200"; d="scan'208";a="138302534" Received: from silpixa00399752.ir.intel.com (HELO silpixa00399752.ger.corp.intel.com) ([10.237.222.212]) by orsmga002.jf.intel.com with ESMTP; 01 Mar 2019 09:32:56 -0800 From: Ferruh Yigit To: dev@dpdk.org, John McNamara , Marko Kovacevic Cc: Neil Horman , Luca Boccassi , Kevin Traynor , Yongseok Koh Date: Fri, 1 Mar 2019 17:32:49 +0000 Message-Id: <20190301173250.80930-2-ferruh.yigit@intel.com> X-Mailer: git-send-email 2.20.1 In-Reply-To: <20190301173250.80930-1-ferruh.yigit@intel.com> References: <20190124181019.17168-1-ferruh.yigit@intel.com> <20190301173250.80930-1-ferruh.yigit@intel.com> MIME-Version: 1.0 Subject: [dpdk-dev] [PATCH v5 2/3] doc: make RTE_NEXT_ABI optional 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" Initial process requires oncoming changes described in deprecation notice should be implemented in a RTE_NEXT_ABI gated way. This has been discussed in technical board, and since this can cause a multiple #ifdef blocks in multiple locations of the code, can be confusing specially for the modifications that requires data structure changes. Anyway this was not happening in practice. Making RTE_NEXT_ABI usage more optional based on techboard decision: http://mails.dpdk.org/archives/dev/2019-January/123519.html The intention with using RTE_NEXT_ABI was to provide more information to the user about planned changes, and force developer to think more in coding level. Since RTE_NEXT_ABI become optional, now the preferred way to do this is, if possible, sending changes, described in deprecation notice, as a separate patch and reference it in deprecation notice. Signed-off-by: Ferruh Yigit Acked-by: Neil Horman --- Cc: Luca Boccassi Cc: Kevin Traynor Cc: Yongseok Koh Cc: Neil Horman --- doc/guides/contributing/versioning.rst | 15 ++++++--------- 1 file changed, 6 insertions(+), 9 deletions(-) diff --git a/doc/guides/contributing/versioning.rst b/doc/guides/contributing/versioning.rst index 0bd7e6c44..2fcb8bafd 100644 --- a/doc/guides/contributing/versioning.rst +++ b/doc/guides/contributing/versioning.rst @@ -73,19 +73,16 @@ being provided. The requirements for doing so are: 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. - It will become the default ABI in the next release. +#. The changes (including an alternative map file) can be included with + deprecation notice, in wrapped way by the ``RTE_NEXT_ABI`` option, + to provide more details about oncoming changes. + ``RTE_NEXT_ABI`` wrapper will be removed when it become the default ABI. + More preferred way to provide this information is sending the feature + as a separate patch and reference it in deprecation notice. #. A full deprecation cycle, as explained above, must be made to offer downstream consumers sufficient warning of the change. -#. At the beginning of the next release cycle, every ``RTE_NEXT_ABI`` - conditions will be removed, the ``LIBABIVER`` variable in the makefile(s) - where the ABI is changed will be incremented, and the map files will - be updated. - Note that the above process for ABI deprecation should not be undertaken lightly. ABI stability is extremely important for downstream consumers of the DPDK, especially when distributed in shared object form. Every effort should