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.
