Re: [dpdk-dev] RFC: DPDK Long Term Support

["Mcnamara, John" <john.mcnamara@intel.com>]

> -----Original Message-----
> From: Neil Horman [mailto:nhorman@tuxdriver.com]
> Sent: Sunday, June 5, 2016 7:15 PM
> To: Mcnamara, John <john.mcnamara@intel.com>
> Cc: dev <dev@dpdk.org>; Christian Ehrhardt
> <christian.ehrhardt@canonical.com>; Markos Chandras <mchandras@suse.de>;
> Panu Matilainen <pmatilai@redhat.com>
> Subject: Re: [dpdk-dev] RFC: DPDK Long Term Support
> 
> >
> 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
> 
> Those two mechanism are expressly intended to allow application upgrades
> of DPDK libraries without worrying about ABI breakage.  

Hi,

The purpose of the LTS proposal isn't to replace or circumvent the ABI policy.
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 case
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 
single version (or, if there is support, versions) and combine their efforts.


> 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 compatibility
and it only gives developers leverage if we allow it to.

John.
--