[dpdk-dev] [PATCH v9 2/4] doc: changes to abi policy introducing major abi versions

[Ray Kinsella]

On 08/11/2019 17:11, Thomas Monjalon wrote:
> 08/11/2019 13:46, Ray Kinsella:
>> This policy change introduces major ABI versions, these are
>> declared every year, typically aligned with the LTS release
>> and are supported by subsequent releases in the following year.
>> This change is intended to improve ABI stabilty for those projects
>> consuming DPDK.
>>
>> Signed-off-by: Ray Kinsella <mdr at ashroe.eu>
>> Acked-by: John Mcnamara <john.mcnamara at intel.com>
>> Acked-by: Stephen Hemminger <stephen at networkplumber.org>
> 
> Acked-by: Thomas Monjalon <thomas at monjalon.net>
> 
>> ---
>> +#. Major ABI versions are declared no more frequently than yearly. Compatibility
>> +   with the major ABI version is mandatory in subsequent releases until a new
>> +   major ABI version is declared.
>> +#. Major ABI version are usually but not always declared aligned with a
>> +   :ref:`LTS release <stable_lts_releases>`.
> 
> OK thanks
> 
>> +#. The ABI version is managed at a project level in DPDK, with the ABI version
>> +   reflected in all library's soname.
> 
> It is not specifying the experimental lib exception.
> But I can live without it.

I will fix in a follow up on Monday.

> 
>> +A new major ABI version is declared no more frequently than yearly, with
>> +declarations usually aligning with a LTS release, e.g. ABI 20 for DPDK 19.11.
>> +Compatibility with the major ABI version is then mandatory in subsequent
>> +releases until the next major ABI version is declared, e.g. ABI 21 for DPDK
>> +20.11.
> 
> OK thanks
> 
>> +   Note that, this policy details the method by which the ABI may be changed,
>> +   with due regard to preserving compatibility and observing deprecation
>> +   notices. This process however should not be undertaken lightly, as a general
>> +   rule ABI stability is extremely important for downstream consumers of DPDK.
>> +   The API should only be changed for significant reasons, such as performance
>> +   enhancements. API breakages due to changes such as reorganizing public
>> +   structure fields for aesthetic or readability purposes should be avoided.
> 
> OK thanks
> 
>> +Libraries marked as ``experimental`` are entirely not considered part of an ABI
>> +version, and may change without warning at any time. Experimental libraries
>> +always have a major version of ``0`` to indicate they exist outside of
>> +ABI Versioning, with the minor version incremented with each ABI change
>> +to library.
> 
> OK
> 
>