From mboxrd@z Thu Jan 1 00:00:00 1970 From: Thomas Monjalon Subject: Re: [PATCH v4 2/3] doc: make RTE_NEXT_ABI optional Date: Thu, 31 Jan 2019 18:18:27 +0100 Message-ID: <3289656.GD5XrPAHiC@xps> References: <20190122162310.53613-1-ferruh.yigit@intel.com> <20190124181019.17168-1-ferruh.yigit@intel.com> <20190124181019.17168-2-ferruh.yigit@intel.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7Bit Cc: dev@dpdk.org, John McNamara , Marko Kovacevic , Luca Boccassi , Kevin Traynor , Yongseok Koh , Neil Horman To: Ferruh Yigit Return-path: Received: from out1-smtp.messagingengine.com (out1-smtp.messagingengine.com [66.111.4.25]) by dpdk.org (Postfix) with ESMTP id BACB81B47E for ; Thu, 31 Jan 2019 18:18:30 +0100 (CET) In-Reply-To: <20190124181019.17168-2-ferruh.yigit@intel.com> List-Id: DPDK patches and discussions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: dev-bounces@dpdk.org Sender: "dev" 24/01/2019 19:10, Ferruh Yigit: > 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 Acked-by: Thomas Monjalon