From mboxrd@z Thu Jan 1 00:00:00 1970 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) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=6wind-com.20150623.gappssmtp.com; s=20150623; h=from:to:cc:subject:date:message-id:user-agent:in-reply-to :references:mime-version:content-transfer-encoding; bh=Oz7eNsXyv+oWvWBViSpyf1q2NuRcGUYNrLyvZZuwDac=; b=Pz47jQbuvLc7t26TcbxsJQGsYHoQC7C1ixLXkCQQvzP4lnQ4faaZu0pqE85IysTdHI yBHKQuiThrYqo0iSCb05Sj4nsrX4vfaGhEsAhfWHEOvB08raMGpGC6e2j9HRhd8xfVVf xt0gNAAdK39BfHIHHpQKyWywQzxsZWOVqsxuhxUD2cftR3kEC6Q5lRx1EqGMV7wI6FQ0 5mV7mDoAErJdj4jnZNy3zEpmlaqMZMwMoCafRgNk9UvT1lPO+ytAsgZluulhqEmMoWxh bVIO1Tjv3g5gSIRYkmSs/UXhRi4Kqm4JzZe+YZ8tkPBPKafmysKZnTspD6vZrvB53rO9 8rog== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:from:to:cc:subject:date:message-id:user-agent :in-reply-to:references:mime-version:content-transfer-encoding; bh=Oz7eNsXyv+oWvWBViSpyf1q2NuRcGUYNrLyvZZuwDac=; b=CS2AvUEC9F/Qh3jTzkmZ1ff7E/16t/cwBJx64bUHzzwVC88ePiLIet90/wAktNOlsj fYs7i4ZhsypCozk+p8kinrMQgP1mMijLwX0+PRjenRqycPiHXSQ633t7PWGK5wyXrEAS u+ItiDa1iWCyL4VNkiDI+fxNva5zTK6I12QhENqY6aQ/AVs6155WhUaVgqJVfgrBQ6hI iItpc/WxeJhPK4MrbQ9hwMQBymZ0ZiTcQX61MN+OxTJZVO6Umx8thnshV30A/QQ88SCo 95flFN6A9FGnFs3b9L+2vk1ua6TCvZjhPVljGr7z0xvAaZdskOifeDacUFFnb4W+CIfM wVdQ== X-Gm-Message-State: ALyK8tLaq9TOzZwcTbrXAq3WOdqVhBJf9AjOgW00XZrxu1E9DGglMEOMZ3aiNzk9a/mgyLWq X-Received: by 10.195.11.34 with SMTP id ef2mr12010214wjd.67.1465205251170; Mon, 06 Jun 2016 02:27:31 -0700 (PDT) Received: from xps13.localnet (184.203.134.77.rev.sfr.net. [77.134.203.184]) by smtp.gmail.com with ESMTPSA id z7sm3011699wjk.6.2016.06.06.02.27.30 (version=TLSv1/SSLv3 cipher=OTHER); Mon, 06 Jun 2016 02:27:30 -0700 (PDT) From: Thomas Monjalon To: Neil Horman Cc: dev@dpdk.org, "Mcnamara, John" , Christian Ehrhardt , Markos Chandras , Panu Matilainen Date: Mon, 06 Jun 2016 11:27:29 +0200 Message-ID: <37570042.soqC7jPioi@xps13> User-Agent: KMail/4.14.10 (Linux/4.5.4-1-ARCH; KDE/4.14.11; x86_64; ; ) In-Reply-To: <20160605181513.GA11762@neilslaptop.think-freely.org> References: <20160605181513.GA11762@neilslaptop.think-freely.org> MIME-Version: 1.0 Content-Transfer-Encoding: 7Bit Content-Type: text/plain; charset="us-ascii" Subject: Re: [dpdk-dev] RFC: DPDK Long Term Support X-BeenThere: dev@dpdk.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: patches and discussions about DPDK List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 06 Jun 2016 09:27:31 -0000 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.