From mboxrd@z Thu Jan 1 00:00:00 1970 From: Thomas Monjalon Subject: Re: RFC: DPDK Long Term Support Date: Mon, 06 Jun 2016 11:27:29 +0200 Message-ID: <37570042.soqC7jPioi@xps13> References: <20160605181513.GA11762@neilslaptop.think-freely.org> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7Bit Cc: dev@dpdk.org, "Mcnamara, John" , Christian Ehrhardt , Markos Chandras , Panu Matilainen To: Neil Horman Return-path: Received: from mail-wm0-f45.google.com (mail-wm0-f45.google.com [74.125.82.45]) by dpdk.org (Postfix) with ESMTP id 70304377C for ; Mon, 6 Jun 2016 11:27:31 +0200 (CEST) Received: by mail-wm0-f45.google.com with SMTP id c74so36292303wme.0 for ; Mon, 06 Jun 2016 02:27:31 -0700 (PDT) In-Reply-To: <20160605181513.GA11762@neilslaptop.think-freely.org> 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" 2016-06-05 14:15, Neil Horman: > On Fri, Jun 03, 2016 at 03:07:49PM +0000, Mcnamara, John wrote: > > Introduction > > ------------ > > > > This document sets out a proposal for a DPDK Long Term Support release (LTS). > > > > The purpose of the DPDK LTS will be to maintain a stable release of DPDK with > > backported bug fixes over an extended period of time. This will provide > > downstream consumers of DPDK with a stable target on which to base > > applications or packages. [...] > I'm not opposed to an LTS release, but it seems to be re-solving the issue 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: > > 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 Sorry I don't understand your point. We are talking about two different things: 1/ ABI care for each new major release 2/ Minor release for bug fixes I think both may exist. > Those two mechanism are expressly intended to allow application upgrades of DPDK > libraries without worrying about ABI breakage. 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 No it was not stated that upstream developers should ignore ABI compatibility. Do you mean having a stable branch means ABI preservation for the next major release is less important? > LTS is a fine process for projects in which API/ABI breakage is either uncommon > or fairly isolated, but that in my mind doesn't really describe DPDK. Yes API/ABI breakages are still common in DPDK. So it's even more important to have some stable branches.