2015-12-07 18:48, Panu Matilainen: > On 12/07/2015 03:55 PM, Thomas Monjalon wrote: > > 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. > > Heh, now that I look more carefully... it IS documented, line 38 of > contributing/versioning.rst: > > > ABI versions are set at the time of major release labeling, and the > > ABI may change multiple times, without warning, between the last > > release label and the HEAD label of the git tree.
Interesting :) > >> 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. > > What I'm thinking of is something that would tie LIBABIVER to the > deprecation announcement in a way that could be easily checked > (programmatically and manually). As it is now, its quite non-trivial to > figure what LIBABIVER *should* be for a given library at a given point - > you need to dig up deprecation.rst history and Makefile history and > whatnot, and its all quite error-prone. Yes clearly we need a safer process. You are welcome to suggest one. I like the idea of being based on some "parse-able" RST changes.
