From mboxrd@z Thu Jan 1 00:00:00 1970 From: "Mcnamara, John" Subject: Re: RFC: DPDK Long Term Support Date: Tue, 7 Jun 2016 15:55:56 +0000 Message-ID: References: <20160605181513.GA11762@neilslaptop.think-freely.org> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Cc: dev , Christian Ehrhardt , Markos Chandras , Panu Matilainen To: Neil Horman Return-path: Received: from mga09.intel.com (mga09.intel.com [134.134.136.24]) by dpdk.org (Postfix) with ESMTP id 867019611 for ; Tue, 7 Jun 2016 17:56:00 +0200 (CEST) In-Reply-To: <20160605181513.GA11762@neilslaptop.think-freely.org> Content-Language: en-US List-Id: patches and discussions about DPDK List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: dev-bounces@dpdk.org Sender: "dev" > -----Original Message----- > From: Neil Horman [mailto:nhorman@tuxdriver.com] > Sent: Sunday, June 5, 2016 7:15 PM > To: Mcnamara, John > Cc: dev ; Christian Ehrhardt > ; Markos Chandras ; > Panu Matilainen > Subject: Re: [dpdk-dev] RFC: DPDK Long Term Support >=20 > > > I'm not opposed to an LTS release, but it seems to be re-solving the issu= e > of ABI breakage. That is to say, there is alreay a process in place for > managing ABI changes to the DPDK, which is designed to help ensure that: >=20 > 1) ABI changes are signaled at least 2 releases early > 2) ABI changes whenever possible are designed such that backward > compatibility versions can be encoded at the same time with versioning > tags >=20 > Those two mechanism are expressly intended to allow application upgrades > of DPDK libraries without worrying about ABI breakage. =20 Hi, The purpose of the LTS proposal isn't to replace or circumvent the ABI poli= cy. In fact backporting of patches would be very difficult without an upstream ABI policy. Even if the ABI policy was working perfectly there would still be a use cas= e for an LTS among consumers who want a fixed version with bug fixes or minor changes. There are already several companies maintaining their own branches like this. This purpose of this proposal is to get them to converge on a=20 single version (or, if there is support, versions) and combine their effort= s. > While LTS releases > are a fine approach for some things, they sacrifice upstream efficiency > (by creating work for backporting teams), while allowing upstream > developers more leverage to just create ABI breaking changes on a whim, > ignoring the existing ABI compatibility mechanism An LTS release doesn't prevent us from maintaining upstream ABI compatibili= ty and it only gives developers leverage if we allow it to. John. --=20