From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mails.dpdk.org (mails.dpdk.org [217.70.189.124]) by inbox.dpdk.org (Postfix) with ESMTP id C44CFA0C4B; Sat, 6 Nov 2021 08:46:18 +0100 (CET) Received: from [217.70.189.124] (localhost [127.0.0.1]) by mails.dpdk.org (Postfix) with ESMTP id 339C34067C; Sat, 6 Nov 2021 08:46:18 +0100 (CET) Received: from wout3-smtp.messagingengine.com (wout3-smtp.messagingengine.com [64.147.123.19]) by mails.dpdk.org (Postfix) with ESMTP id 850E240151 for ; Sat, 6 Nov 2021 08:46:16 +0100 (CET) Received: from compute1.internal (compute1.nyi.internal [10.202.2.41]) by mailout.west.internal (Postfix) with ESMTP id CC4EB3200A2A; Sat, 6 Nov 2021 03:46:14 -0400 (EDT) Received: from mailfrontend1 ([10.202.2.162]) by compute1.internal (MEProxy); Sat, 06 Nov 2021 03:46:15 -0400 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=fm2; bh= CbMDMZMoDkcErhzXwy4xpuBPoOMNj0uixm1gHVndRd4=; b=kz2f+7U5ykgih275 dMFD4fzCtmLMq71syvi2fd8z2IVKxWDWzwg2q/Yws/zw2MWkB+gcqDVQjaqJMhuk JxXwAD31lRA5ABm0vtlMgCkbfdy4e1wY98xuQG75A73QHfRfV9zR/ZiAyAhiS4xG uVuv5M02eFmPfpmuUDp69ep1plYnAk7BQE8tzPkAvbp5gBPWeFVAq/ebeKaJDau9 NTB2/ieKZRk6eYxpzODowMp/kIyjGdcQU9fME2zc+/NUC72TzfFKF7u7j4ldv7Da uDUKGqOPSKtG7AXGoGmf97fRkgqKOf1icBf7KysVSj/+HgUi9T1GQAG8gnuzhJ0+ HBq0gQ== 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=CbMDMZMoDkcErhzXwy4xpuBPoOMNj0uixm1gHVndR d4=; b=L1o75XymXYtSOhImJ2+HQOVYrX0rhRn9uVs/rSkV6X5FKd2+bVl1zoYZc 5PrYh+buNU+HaWkiJcnABgkyGGD/KzgqphWceymHlKr5RKieMqekPrOOssykKi9V LDhN9aATkF1FZe60NvqleYNMSXON68ho39byddq7FOpaazldybPpDQ3D+6vj3ZMn fpgbqIsLwacg+YpT9fxHwzo7Owtrm6KoqsDBTG1ysTF58jia44drCPIa8uqK8aHw EwUg6ls4UNeHp1nnPBtPdjXl4wb56+Jrpwk5gH0JUXS2ECKQ3gChNzIvitH3ZQGz 6ZyBkgTBw3rkg/OcSgIAdc7WzOH3Q== X-ME-Sender: X-ME-Received: X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgedvuddrtdejgddutdegucetufdoteggodetrfdotf fvucfrrhhofhhilhgvmecuhfgrshhtofgrihhlpdfqfgfvpdfurfetoffkrfgpnffqhgen uceurghilhhouhhtmecufedttdenucesvcftvggtihhpihgvnhhtshculddquddttddmne cujfgurhephffvufffkfgjfhgggfgtsehtufertddttddvnecuhfhrohhmpefvhhhomhgr shcuofhonhhjrghlohhnuceothhhohhmrghssehmohhnjhgrlhhonhdrnhgvtheqnecugg ftrfgrthhtvghrnhepudeggfdvfeduffdtfeeglefghfeukefgfffhueejtdetuedtjeeu ieeivdffgeehnecuvehluhhsthgvrhfuihiivgeptdenucfrrghrrghmpehmrghilhhfrh homhepthhhohhmrghssehmohhnjhgrlhhonhdrnhgvth X-ME-Proxy: Received: by mail.messagingengine.com (Postfix) with ESMTPA; Sat, 6 Nov 2021 03:46:13 -0400 (EDT) From: Thomas Monjalon To: Stephen Hemminger , Ferruh Yigit , Andrew Rybchenko Cc: dev@dpdk.org, David Marchand , Olivier Matz Date: Sat, 06 Nov 2021 08:46:11 +0100 Message-ID: <2693174.exs4cmyxhT@thomas> In-Reply-To: <7f14a405-a861-dd9d-8fea-015ba25187f1@intel.com> References: <20211102234434.2639807-1-ferruh.yigit@intel.com> <20211105092649.32fadae4@hermes.local> <7f14a405-a861-dd9d-8fea-015ba25187f1@intel.com> MIME-Version: 1.0 Content-Transfer-Encoding: 7Bit Content-Type: text/plain; charset="us-ascii" Subject: Re: [dpdk-dev] [PATCH v2] ethdev: mark old macros as deprecated X-BeenThere: dev@dpdk.org X-Mailman-Version: 2.1.29 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" 05/11/2021 22:33, Ferruh Yigit: > On 11/5/2021 4:26 PM, Stephen Hemminger wrote: > > On Fri, 05 Nov 2021 16:05:14 +0100 > > Thomas Monjalon wrote: > > > >>>>> > >>>>> What do you think about marking old macros as deprecated? > >>>>> > >>>>> This will cause warning in application code that is using > >>>>> old macros, but shouldn't fail their build (unless -Werror > >>>>> is issued). > >>>> > >>>> It looks to be the right thing to do. > >>>> I wonder whether we could wait 22.02 to apply it, > >>>> so users of LTS are not annoyed by it. > >>> > >>> I have no strong opinion, but tend to agree with Thomas. > >>> However, if an application jumps from LTS to LTS, these > >>> defines will be available in 21.11 without any warnings > >>> and simply disappear in 22.11. So, may be it is more > >>> friendly to deprecate in 21.11. > >> > >> That's true for a lot of deprecations done in the year. > >> Jumping from LTS to LTS is for production. > >> Intermediate releases should help in the upgrade preparation process. > > > > Agree, the deprecation cycle is long enough and it is just a > > trivial warning easy to fix, or for those that ignore warnings > > they just won't care. > > > > I think Thomas is suggesting to postpone the patch to v22.02, is it > what you agree? > > If so, plan is: > - Have v21.11 without this patch. So backward compatibility macros > won't be deprecated in v21.11, and end users won't be affected > from the rename at all. > - v22.02 will have this patch that deprecates the old macros. End > user will get build warnings after this point. > - Remove deprecated macros on v22.11. If this time is agreed on, > I will send a deprecation notice patch for it. That's exactly my thinking.