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 3DA5FB38D for ; Mon, 7 Dec 2015 18:48:23 +0100 (CET) Received: by wmec201 with SMTP id c201so161317720wme.1 for ; Mon, 07 Dec 2015 09:48:23 -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=9Bm8uMcl3N9QBNJCOUeajFn9haYUgnLO+ycmYRWgmfQ=; b=lVMeTYBwWLg17Fd5xix5kw/XhgG/TevPWSiGC3w90lyPweUABSfxdbyj/GzQgbRMv7 avr9nzGjjuFVksy48Os5CvL6okggl1Mz5R2tx1hALRwQu0pAagsnGEsvSNLG1fbKNwuz b6xWtGyGs5Dk3faOjeaRW4fsL5uSfGj3AkNm/Wy6iQU3DKEgq1lnGYSIwpTNQx+Aiz0P 7m15V4Kp5cemzrsIZ6V0WCCLPNSWFrXXAfGg9AovedZEH+wjYq5hNFQ98QU8q8Q1FEyr 4V9y7gKTnI0SOdSlu9fF+Ujlek/f7p6gyVZ6j3zcJ5WRD2LM6sIODUKoUMeIpBOqKvLi 14ww== 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=9Bm8uMcl3N9QBNJCOUeajFn9haYUgnLO+ycmYRWgmfQ=; b=fh4O4wLsKnoV0C1uUeax7IuTAugsBt3s7Hsg2OwqHIXK48fVA1DINV8lE1KKyM9+zD O/fezU6vlCrLLLrpqlJsR3AmY/Xk3Zm6u0uNIJ6Quy6lWcAQrQdOHW2KhaMQyerGnRr8 wYtuXZXg0d9N/rXMKE6F70Gp/DM4p8BYodlv4+e5KUS4jNUGwelzQ2Z+6adS0fILOgAX c1zvUiLanfm0/rQ2htEdBIKLzdQ2/quHGDN70pZ/rBVqwQE0oAube5TkIWcwu81B16Vk fUF4i297jrzFqGie7eZoPT+QNqyUZyASSJwdltyQX8DJXjDespAdRG5BINr/8cB4hSNN URAA== X-Gm-Message-State: ALoCoQnBDQaQMZhtucgcCzuyOaJboeyLdK0yqzXUl+Tlv+FAOf5OWgFL5vyH0ViqUtB2CKr0ZozuEvh2vojN4ELG6Bc2yTSPlA== X-Received: by 10.28.86.196 with SMTP id k187mr21769682wmb.61.1449510503082; Mon, 07 Dec 2015 09:48:23 -0800 (PST) Received: from xps13.localnet (136-92-190-109.dsl.ovh.fr. [109.190.92.136]) by smtp.gmail.com with ESMTPSA id f11sm17780537wmd.7.2015.12.07.09.48.21 (version=TLSv1/SSLv3 cipher=OTHER); Mon, 07 Dec 2015 09:48:22 -0800 (PST) From: Thomas Monjalon To: Panu Matilainen Date: Mon, 07 Dec 2015 18:47:09 +0100 Message-ID: <2017983.ziakAAqF0A@xps13> Organization: 6WIND User-Agent: KMail/4.14.10 (Linux/4.1.6-1-ARCH; KDE/4.14.11; x86_64; ; ) In-Reply-To: <5665B84B.4000900@redhat.com> References: <1449027793-30975-1-git-send-email-yuanhan.liu@linux.intel.com> <32221385.fypBVK5OXa@xps13> <5665B84B.4000900@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 17:48:23 -0000 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.