2015-12-07 13:41, Panu Matilainen: > On 12/07/2015 01:28 PM, Thomas Monjalon wrote: > > 2015-12-07 08:29, Panu Matilainen: > >> On 12/07/2015 01:07 AM, Thomas Monjalon wrote: > >>> 2015-12-02 15:53, Panu Matilainen: > >> The vhost ABI break was announced for DPDK 2.2 in commit > >> 3c848bd7b1c6f4f681b833322a748fdefbb5fb2d: > > [...] > >> So the ABI process was properly followed, except for actually bumping > >> LIBABIVER. Bumping LIBABIVER is mentioned in > >> doc/guides/contributing/versioning.rst but it doesn't specify *when* > >> this should be done, eg should the first patch breaking the ABI bump it > >> or should it done be shortly before the next stable release, or > >> something else. As it is, it seems a bit too easy to simply forget. > > > > I thought it was not needed to explicitly say that commits must be atomic > > and we do not have to wait to do the required changes. > > The "problem" is that during a development cycle, an ABI could be broken > several times but LIBABIVER should only be bumped once. So ABI breaking > commits will often not be atomic wrt LIBABIVER, no matter which way its > done.
If the ABI version has already been changed, there should be a merge conflict. I think it's better to manage a conflict than forget to update the version. > For example libtool recommendation is that library versions are updated > only just before public releases: > https://www.gnu.org/software/libtool/manual/html_node/Updating-version-info.html#Updating-version-info Interesting link. It makes me think that we do not manage ABI break when downgrading the library (case of only new API keeping the ABI number). > > In this case, I've missed it when reviewing the vhost patches breaking the > > ABI.
