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: >>>> This (and other changes in patch 2 breaks the librte_vhost ABI again, so >>>> you'd need to at least add a deprecation note to 2.2 to be able to do it >>>> in 2.3 at all according to the ABI policy. >>>> >>>> Perhaps a better option would be adding some padding to the structs now >>>> for 2.2 since the vhost ABI is broken there anyway. That would at least >>>> give a chance to keep it compatible from 2.2 to 2.3. >>> >>> Please could you point where the vhost ABI is broken in 2.2? >>> >> >> 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. 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 - Panu - > In this case, I've missed it when reviewing the vhost patches breaking the > ABI. >
