From: Ray Kinsella <mdr@ashroe.eu>
To: dev@dpdk.org
Subject: Re: [dpdk-dev] ABI version of experimental libraries
Date: Wed, 19 Feb 2020 13:50:33 +0000 [thread overview]
Message-ID: <6de88cc1-4766-b59a-e138-0b3978f58d5d@ashroe.eu> (raw)
In-Reply-To: <5254976.hdfAi7Kttb@xps>
On 19/02/2020 12:43, Thomas Monjalon wrote:
> 19/02/2020 12:43, Neil Horman:
>> On Tue, Feb 18, 2020 at 10:50:09AM +0100, Thomas Monjalon wrote:
>>> 18/02/2020 10:42, Bruce Richardson:
>>>> On Tue, Feb 18, 2020 at 12:15:56AM +0100, Thomas Monjalon wrote:
>>>>> Hi,
>>>>>
>>>>> I would like to remind everybody our mistake when defining ABI versions.
>>>>> It has been "fixed" in this commit:
>>>>> http://git.dpdk.org/dpdk/commit/?id=f26c2b39
>>>>>
>>>>> Please let's think about the consequence for the experimental libraries.
>>>>>
>>>>> In DPDK 19.11, we use the ABI version 0.200 with soname 0.20 In DPDK
>>>>> 20.02, we use the ABI version 0.2001 with soname 0.201 Numbers are
>>>>> increasing, that's fine. When we'll switch to the new major ABI and use
>>>>> a normal numbering: In DPDK 20.11, we will use the ABI version 0.210 with
>>>>> soname 0.21 Numbers are dropping.
>>>>>
>>>>> In short, for experimental libs, ABI 20.1 > ABI 21.0
>>>>>
>>>>> Are we OK with this or do we prefer reverting to normal numbering for
>>>>> experimental libraries in DPDK 20.02?
>>>>>
>>>> Personally, I would not be too concerned about the verions of experimental
>>>> libs, so long as they don't conflict across versions and have some
>>>> similarity to the major ABI version for the release.
>>>
>>> You think sorting of the version numbers is not important?
>>> If we don't care comparing experimental version numbers,
>>> then OK, let's drop this patch. But please we need a small vote.
>>>
>>> Note: there would be no problem if we did not vote for having
>>> a special numbering for pure experimental libraries (I am still against).
>>>
>> I don't understand. Why would we change the ABI_VERSION at all in an LTS release at
>> all? This operation is meant to take an an experimental API and mark it as
>> stable by promoting its version number to the next major releases number. As
>> such, in the LTS release, we should keep the soname the same, as there should be
>> no other ABI changes in the promoted API.
>
> The library version number is updated because we add new symbols.
>
>
So while experimental library version numbers are not "important".
I do agree with Thomas they should be sane, increase and should have a consistent format.
Should we always just pad them to 4 places as the simple solution?
i.e.
DPDK 19.11 ... 0.20 (needs to remain 0.20).
DPDK 20.02 ... 0.2001
DPDK 20.11 ... 0.2100
DPDK 21.02 ... 0.2101
Make sense?
Ray K
next prev parent reply other threads:[~2020-02-19 13:50 UTC|newest]
Thread overview: 20+ messages / expand[flat|nested] mbox.gz Atom feed top
2020-02-17 23:15 Thomas Monjalon
2020-02-17 23:44 ` [dpdk-dev] [PATCH] build: fix soname for " Thomas Monjalon
2020-02-18 9:40 ` Bruce Richardson
2020-02-18 9:47 ` Thomas Monjalon
2020-02-18 9:42 ` [dpdk-dev] ABI version of " Bruce Richardson
2020-02-18 9:50 ` Thomas Monjalon
2020-02-18 10:36 ` Kinsella, Ray
2020-02-20 19:50 ` Ferruh Yigit
2020-02-20 19:54 ` [dpdk-dev] [PATCH] build: fix experimental library versioning Ferruh Yigit
2020-02-20 22:14 ` Luca Boccassi
2020-02-21 12:36 ` Ray Kinsella
2020-02-21 15:24 ` David Marchand
2020-02-21 15:34 ` Ferruh Yigit
2020-02-21 16:41 ` David Marchand
2020-02-19 11:43 ` [dpdk-dev] ABI version of experimental libraries Neil Horman
2020-02-19 12:43 ` Thomas Monjalon
2020-02-19 13:50 ` Ray Kinsella [this message]
2020-02-21 16:57 ` Thomas Monjalon
2020-02-24 9:32 ` Ray Kinsella
2020-02-19 21:17 ` Neil Horman
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=6de88cc1-4766-b59a-e138-0b3978f58d5d@ashroe.eu \
--to=mdr@ashroe.eu \
--cc=dev@dpdk.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).