On Wed, Feb 19, 2020 at 01:43:01PM +0100, 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. But thats a matter of policy (and possibly build mechanics). Not saying agree with this approach necessecarily (as I've not fully thought it through), but we could make room in the policy for this eventuality.
Neil > > >
