From mboxrd@z Thu Jan  1 00:00:00 1970
Return-Path: <bruce.richardson@intel.com>
Received: from mga02.intel.com (mga02.intel.com [134.134.136.20])
 by dpdk.org (Postfix) with ESMTP id E3C847E18
 for <dev@dpdk.org>; Wed, 19 Nov 2014 12:24:56 +0100 (CET)
Received: from orsmga001.jf.intel.com ([10.7.209.18])
 by orsmga101.jf.intel.com with ESMTP; 19 Nov 2014 03:35:11 -0800
X-ExtLoop1: 1
X-IronPort-AV: E=Sophos;i="5.07,416,1413270000"; d="scan'208";a="610376853"
Received: from bricha3-mobl3.ger.corp.intel.com ([10.243.20.23])
 by orsmga001.jf.intel.com with SMTP; 19 Nov 2014 03:35:08 -0800
Received: by  (sSMTP sendmail emulation); Wed, 19 Nov 2014 11:35:08 +0025
Date: Wed, 19 Nov 2014 11:35:08 +0000
From: Bruce Richardson <bruce.richardson@intel.com>
To: Thomas Monjalon <thomas.monjalon@6wind.com>
Message-ID: <20141119113507.GA2604@bricha3-MOBL3>
References: <5606183.AkpK27L7yz@xps13>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <5606183.AkpK27L7yz@xps13>
Organization: Intel Shannon Ltd.
User-Agent: Mutt/1.5.23 (2014-03-12)
Cc: dev@dpdk.org, Neil Horman <nhorman@redhat.com>
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 <dev.dpdk.org>
List-Unsubscribe: <http://dpdk.org/ml/options/dev>,
 <mailto:dev-request@dpdk.org?subject=unsubscribe>
List-Archive: <http://dpdk.org/ml/archives/dev/>
List-Post: <mailto:dev@dpdk.org>
List-Help: <mailto:dev-request@dpdk.org?subject=help>
List-Subscribe: <http://dpdk.org/ml/listinfo/dev>,
 <mailto:dev-request@dpdk.org?subject=subscribe>
X-List-Received-Date: Wed, 19 Nov 2014 11:24:57 -0000

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