From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from smtp.tuxdriver.com (charlotte.tuxdriver.com [70.61.120.58]) by dpdk.org (Postfix) with ESMTP id 0AEB17F00 for ; Wed, 19 Nov 2014 16:03:34 +0100 (CET) Received: from nat-pool-rdu-t.redhat.com ([66.187.233.202] helo=localhost) by smtp.tuxdriver.com with esmtpsa (TLSv1:AES128-SHA:128) (Exim 4.63) (envelope-from ) id 1Xr6x3-0001lN-EC; Wed, 19 Nov 2014 10:13:57 -0500 Date: Wed, 19 Nov 2014 10:13:43 -0500 From: Neil Horman To: Bruce Richardson Message-ID: <20141119151343.GC28013@localhost.localdomain> References: <5606183.AkpK27L7yz@xps13> <20141119113507.GA2604@bricha3-MOBL3> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20141119113507.GA2604@bricha3-MOBL3> User-Agent: Mutt/1.5.23 (2014-03-12) X-Spam-Score: -2.9 (--) X-Spam-Status: No Cc: dev@dpdk.org, Neil Horman Subject: Re: [dpdk-dev] versioning and maintenance 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: Wed, 19 Nov 2014 15:03:34 -0000 On Wed, Nov 19, 2014 at 11:35:08AM +0000, Bruce Richardson wrote: > On Wed, Nov 19, 2014 at 12:22:14PM +0100, Thomas Monjalon wrote: > > Following the discussion we had with Neil during the conference call, > > I suggest this plan, starting with the next release (2.0): > > - add version numbers to libraries > > - add version numbers to functions inside .map files > > - create a git tree dedicated to maintenance and API compatibility > > > > It means these version numbers must be incremented when breaking the API. > > Though the old code paths will be maintained and tested separately by volunteers. > > A mailing list for maintenance purpose could be created if needed. > > > Hi Thomas, > > I really think that the versionning is best handled inside the main repository > itself. Given that the proposed deprecation policy is over two releases i.e. an > API is marked deprecated in release X and then removed in X+1, I don't see the > maintaining of old code paths to be particularly onerous. > > /Bruce > I agree with Bruce, even if it is on occasion an added workload, its not the sort of thing that can or should be placed on an alternate developer. Backwards compatibility is the sort of thing that has to be on the mind of the developer when modifying an API, and on the mind of the reviewer when reviewing code. To shunt that responsibility elsewhere invites the opportunity for backwards compatibilty to be a second class citizen who's goal will never be reached, because developers instituting ABI changes will never care about the consequences, and anyone worrying about backwards compatibility will always be playing catch up, possibly allowing ABI breaks to slip through. Neil