From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mx1.redhat.com (mx1.redhat.com [209.132.183.28]) by dpdk.org (Postfix) with ESMTP id 4C6729A8A for ; Mon, 7 Dec 2015 17:48:14 +0100 (CET) Received: from int-mx10.intmail.prod.int.phx2.redhat.com (int-mx10.intmail.prod.int.phx2.redhat.com [10.5.11.23]) by mx1.redhat.com (Postfix) with ESMTPS id 4A5E0935D8; Mon, 7 Dec 2015 16:48:13 +0000 (UTC) Received: from sopuli.koti.laiskiainen.org (vpn1-5-85.ams2.redhat.com [10.36.5.85]) by int-mx10.intmail.prod.int.phx2.redhat.com (8.14.4/8.14.4) with ESMTP id tB7GmBPT027179; Mon, 7 Dec 2015 11:48:11 -0500 To: Thomas Monjalon References: <1449027793-30975-1-git-send-email-yuanhan.liu@linux.intel.com> <8246076.3G1fmNTuPH@xps13> <56657074.7000206@redhat.com> <32221385.fypBVK5OXa@xps13> From: Panu Matilainen Message-ID: <5665B84B.4000900@redhat.com> Date: Mon, 7 Dec 2015 18:48:11 +0200 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:38.0) Gecko/20100101 Thunderbird/38.4.0 MIME-Version: 1.0 In-Reply-To: <32221385.fypBVK5OXa@xps13> Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit X-Scanned-By: MIMEDefang 2.68 on 10.5.11.23 Cc: dev@dpdk.org, Victor Kaplansky , "Michael S. Tsirkin" Subject: Re: [dpdk-dev] [PATCH 1/4] vhost: handle VHOST_USER_SET_LOG_BASE request X-BeenThere: dev@dpdk.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: patches and discussions about DPDK List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 07 Dec 2015 16:48:14 -0000 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. >> 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. >> 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). Hmm, not quite sure what you mean here, but full libtool-style versioning is not really needed with symbol versioning. - Panu - > >>> In this case, I've missed it when reviewing the vhost patches breaking the >>> ABI. >