On 21/10/2019 10:50, Thomas Monjalon wrote:
> 27/09/2019 18:54, Ray Kinsella:
>> TL;DR abbreviation:
>> A major ABI version that all DPDK releases during a one year period
>> support. ABI versioning is managed at a project-level, in place of
>> library-level
>> management. ABI changes to add new features are permitted, as long as ABI
>> compatibility with the major ABI version is maintained.
>>
>> Detail:
>> This patch introduces major ABI versions, supported for one year and released
>> aligned with the LTS release. This ABI version is then supported by all
>> subsequent releases within that one year period. The intention is that the
>> one
>> year support period, will then be reviewed after the initial year with the
>> intention of lengthing the support period for the next ABI version.
>
> For the record, I would prefer a v7 saying it is a fixed period of time,
> being one year at first and should be longer next.
> Please don't state "supported for one year", which can be understood as a
> general truth.
Well I was very careful to only state an _intention_ to lengthen the fix period,
I though it prudent to avoid words like "should", as nothing is known until the
year is behind us.
Where I used the word "support", I talk about "abi support".
I suggest rewording as follows:-
This patch introduces major ABI versions, released aligned with the LTS release,
maintained for one year through all subsequent releases within that one year
period.
The intention is that the one year abi support period, will then be reviewed
after
the initial year with the intention of lengthening the period for the next ABI
version.
>
>> ABI changes that preserve ABI compatibility with the major ABI version are
>> permitted in subsequent releases. ABI changes, follow similar approval rules
>> as
>> before with the additional gate of now requiring technical board approval.
>> The
>> merging and release of ABI breaking changes would now be pushed to the
>> declaration of the next major ABI version.
>>
>> This change encourages developers to maintain ABI compatibility with the
>> major
>> ABI version, by promoting a permissive culture around those changes that
>> preserve ABI compatibility. This approach begins to align DPDK with those
>> projects that declare major ABI versions (e.g. version 2.x, 3.x) and support
>> those versions for some period, typically two years or more.
>>
>> To provide an example of how this might work in practice:
>>
>> * DPDK v20 is declared as the supported ABI version for one year, aligned
>> with
>> the DPDK v19.11 (LTS) release. All library sonames are updated to reflect
>> the
>> new ABI version, e.g. librte_eal.so.20, librte_acl.so.20...
>> * DPDK v20.02 .. v20.08 releases are ABI compatible with the DPDK v20 ABI.
>> ABI
>> changes are permitted from DPDK v20.02 onwards, with the condition that
>> ABI
>> compatibility with DPDK v20 is preserved.
>> * DPDK v21 is declared as the new supported ABI version for two years,
>> aligned
>> with the DPDK v20.11 (LTS) release. The DPDK v20 ABI is now depreciated,
>> library sonames are updated to v21 and ABI compatibility breaking changes
>> may
>> be introduced.
>
> OK I agree with these explanations.
>
>
