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 1848CB347
 for <dev@dpdk.org>; Fri, 19 Sep 2014 11:39:53 +0200 (CEST)
Received: from orsmga002.jf.intel.com ([10.7.209.21])
 by orsmga101.jf.intel.com with ESMTP; 19 Sep 2014 02:45:42 -0700
X-ExtLoop1: 1
X-IronPort-AV: E=Sophos;i="5.04,554,1406617200"; d="scan'208";a="605305315"
Received: from bricha3-mobl.ger.corp.intel.com (HELO
 bricha3-mobl.ir.intel.com) ([10.243.20.20])
 by orsmga002.jf.intel.com with SMTP; 19 Sep 2014 02:45:38 -0700
Received: by bricha3-mobl.ir.intel.com (sSMTP sendmail emulation);
 Fri, 19 Sep 2014 10:45:38 +0001
Date: Fri, 19 Sep 2014 10:45:38 +0100
From: Bruce Richardson <bruce.richardson@intel.com>
To: Neil Horman <nhorman@tuxdriver.com>
Message-ID: <20140919094537.GA7568@BRICHA3-MOBL>
References: <1410809031-19114-1-git-send-email-nhorman@tuxdriver.com>
 <1410809031-19114-3-git-send-email-nhorman@tuxdriver.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <1410809031-19114-3-git-send-email-nhorman@tuxdriver.com>
Organization: Intel Shannon Ltd.
User-Agent: Mutt/1.5.22 (2013-10-16)
Cc: dev@dpdk.org
Subject: Re: [dpdk-dev] [PATCH 2/4] Provide initial versioning for all DPDK
	libraries
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: Fri, 19 Sep 2014 09:39:54 -0000

On Mon, Sep 15, 2014 at 03:23:49PM -0400, Neil Horman wrote:
> Add linker version script files to each DPDK library to put a stake in the
> ground from which we can start cleaning up API's
> 
> Signed-off-by: Neil Horman <nhorman@tuxdriver.com>
> CC: Thomas Monjalon <thomas.monjalon@6wind.com>
> CC: "Richardson, Bruce" <bruce.richardson@intel.com>
> ---
>  <... snip for brevity ...>
>
> diff --git a/lib/librte_acl/Makefile b/lib/librte_acl/Makefile
> index 65e566d..1f96645 100644
> --- a/lib/librte_acl/Makefile
> +++ b/lib/librte_acl/Makefile
> @@ -37,6 +37,8 @@ LIB = librte_acl.a
>  CFLAGS += -O3
>  CFLAGS += $(WERROR_FLAGS) -I$(SRCDIR)
>  
> +EXPORT_MAP := $(RTE_SDK)/lib/librte_acl/rte_acl_version.map
> +
>  # all source are stored in SRCS-y
>  SRCS-$(CONFIG_RTE_LIBRTE_ACL) += tb_mem.c
>  
> diff --git a/lib/librte_acl/rte_acl_version.map b/lib/librte_acl/rte_acl_version.map
> new file mode 100644
> index 0000000..4480690
> --- /dev/null
> +++ b/lib/librte_acl/rte_acl_version.map
> @@ -0,0 +1,19 @@
> +DPDK_1.8 {
> +	global:
> +	rte_acl_create;
> +	rte_acl_find_existing;
> +	rte_acl_free;
> +	rte_acl_add_rules;
> +	rte_acl_reset_rules;
> +	rte_acl_build;
> +	rte_acl_reset;
> +	rte_acl_classify;
> +	rte_acl_dump;
> +	rte_acl_list_dump;
> +	rte_acl_ipv4vlan_add_rules;
> +	rte_acl_ipv4vlan_build;
> +	rte_acl_classify_scalar;
> +
> +	local: *;
> +};
> +

Looking at this versionning, it strikes me that this looks like the perfect 
opportunity to go to a 2.0 version number.

My reasoning:
* We have already got fairly significant ABI and indeed API changes in this 
  release due to the mbuf rework. That allow makes it a logical point to 
  bump the Intel DPDK major version number to 2.0
* Having the API versioning start at a 2.0 looks neater than having it at 
  1.8, since .0 is a nice round version number to start with. Also if we 
  decide in the near future for whatever reasons to go to a 2.0 release, the 
  ABIs are probably still going to be 1.8. [Again, if we ever want to go to 
  2.0, now looks the perfect time]
* For the naming of the .so files, starting with them at a .2 now seems 
  reasonable to me, denoting a clean break with the older releases which did 
  have a different ABI. [Though again it makes more sense if you consider 
  that we may want to move to a 2.0 in future].

What do people think?

/Bruce