From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-wm0-f45.google.com (mail-wm0-f45.google.com [74.125.82.45]) by dpdk.org (Postfix) with ESMTP id 3C1F795CD for ; Mon, 7 Dec 2015 14:57:10 +0100 (CET) Received: by wmuu63 with SMTP id u63so141454736wmu.0 for ; Mon, 07 Dec 2015 05:57:10 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=6wind-com.20150623.gappssmtp.com; s=20150623; h=from:to:cc:subject:date:message-id:organization:user-agent :in-reply-to:references:mime-version:content-transfer-encoding :content-type; bh=1A1fLHwf6laRE0CKUwNlkqHV3RG/pwTs4AbawsLM0M8=; b=Vg4yBhqfknoHLZudfson7t/MEzQGaBbu/q1l4Pf70AjT4Fv25ZylmDubbQtdJUNrwO N+ZiVaJSZ74R5Y+mSwSX4BesCJX9Xhxwaz+FzUJM1Y2FM5ROc7ZtCjt/Ai2WCMJzddX8 qxHbHXN4lcLT/JwqT3Jnd0uxlTHfIxiEdQRW+9myG8/Tza+6zaMm9HEyQZGQ4i6mFYSg rcPtZSGInZU+ufwQJcWWZ0mwB6QvAn88sJAtOTcFcHhwF3E1f5iXVZ4VTNAWmuyb20Qy vX+BE/5vyaM8moX7mUgBSlbv7HI3v3pAY0V8FKLRXYCtTjGkVCl9n92hg51m1NRkIT+o UL/Q== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:from:to:cc:subject:date:message-id:organization :user-agent:in-reply-to:references:mime-version :content-transfer-encoding:content-type; bh=1A1fLHwf6laRE0CKUwNlkqHV3RG/pwTs4AbawsLM0M8=; b=Wbo27BsfYyAJPhLeU5N4797A3RnxGTQgwBj8Q9S4kwvlJG5cGXvDnu++96r1Yh5uF1 C7cFEyrr2EXZK77gz2F4CSpAHQkP1xxGvHCvnIidA2q4HxdVOaxOBCLcdNOwAZ5UyWhO MGpP2ApQE8LfTTzlACMrwQdGlH5ROQMhHAbw+LHq360sML71uZ/YbLnmaWFQ3C7VxTV+ WOSSih0KrA+7wETClYLg6siM9wfJjJQ5x28BaXk8QxLa3iI4bLjG//cY6M+BKiylEFmR cyrCDpJ89WsU4zAqFnAyKiUdqr83OIkdh1geYoedd7ZHoTBef9/CJqDXmkjUwTfqbi4v uHLA== X-Gm-Message-State: ALoCoQkXT1NrvDTGVR9Uuxeqd0SB7tDuztp1zVCqKYUJBOm644CSyRUUBRZ2hF7qKQVozYXo5QFB X-Received: by 10.28.148.147 with SMTP id w141mr22622345wmd.14.1449496629994; Mon, 07 Dec 2015 05:57:09 -0800 (PST) Received: from xps13.localnet (136-92-190-109.dsl.ovh.fr. [109.190.92.136]) by smtp.gmail.com with ESMTPSA id m67sm16840424wmf.16.2015.12.07.05.57.08 (version=TLSv1/SSLv3 cipher=OTHER); Mon, 07 Dec 2015 05:57:09 -0800 (PST) From: Thomas Monjalon To: Panu Matilainen Date: Mon, 07 Dec 2015 14:55:56 +0100 Message-ID: <32221385.fypBVK5OXa@xps13> Organization: 6WIND User-Agent: KMail/4.14.10 (Linux/4.1.6-1-ARCH; KDE/4.14.11; x86_64; ; ) In-Reply-To: <56657074.7000206@redhat.com> References: <1449027793-30975-1-git-send-email-yuanhan.liu@linux.intel.com> <8246076.3G1fmNTuPH@xps13> <56657074.7000206@redhat.com> MIME-Version: 1.0 Content-Transfer-Encoding: 7Bit Content-Type: text/plain; charset="us-ascii" 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 13:57:10 -0000 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.