From mboxrd@z Thu Jan  1 00:00:00 1970
From: Thomas Monjalon <thomas.monjalon@6wind.com>
Subject: Re: [PATCH 2/3] version: adjust printing for new version
	scheme
Date: Mon, 28 Dec 2015 23:25:10 +0100
Message-ID: <7956038.7RoB3127Jy@xps13>
References: <1450704384-9986-1-git-send-email-bruce.richardson@intel.com>
 <1450704384-9986-3-git-send-email-bruce.richardson@intel.com>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7Bit
Cc: dev@dpdk.org
To: Bruce Richardson <bruce.richardson@intel.com>
Return-path: <dev-bounces@dpdk.org>
Received: from mail-pf0-f179.google.com (mail-pf0-f179.google.com
 [209.85.192.179]) by dpdk.org (Postfix) with ESMTP id D4E799190
 for <dev@dpdk.org>; Mon, 28 Dec 2015 23:26:23 +0100 (CET)
Received: by mail-pf0-f179.google.com with SMTP id e65so65672609pfe.1
 for <dev@dpdk.org>; Mon, 28 Dec 2015 14:26:23 -0800 (PST)
In-Reply-To: <1450704384-9986-3-git-send-email-bruce.richardson@intel.com>
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>
Errors-To: dev-bounces@dpdk.org
Sender: "dev" <dev-bounces@dpdk.org>

2015-12-21 13:26, Bruce Richardson:
> Since we are now using a year-month numbering scheme, adjust
> the printing of the version to always use 2-digits for YY.MM
> format.

Yes
It must be done for "make showversion" also.

> Also omit the patch version unless there is a patch version present,
> since patches for releases are rare on DPDK. This means that the
> final release of 16.04 will report as 16.04, rather than 16.04.0.

So the numbering of master and maintenance releases will not be consistent:
	16.04 and then 16.04.1
It's true that maintenance releases are rare but it has been discussed at
Dublin to have ones in future.
So are we OK to omit the .0 even if not consistent?

> Release candidates for it will similarly report as 16.04-rcX.

Yes, 16.04-rcX looks nicer than 16.04.0-rcX.

Shouldn't we take the opportunity to update RTE_VER_PREFIX from
"RTE" to "DPDK"?

>  /**
>   * Major version number i.e. the x in x.y.z
>   */
> -#define RTE_VER_MAJOR 16
> +#define RTE_REL_YEAR 16
>  
>  /**
>   * Minor version number i.e. the y in x.y.z
>   */
> -#define RTE_VER_MINOR 4
> +#define RTE_REL_MONTH 4

Why renaming from _VER_ to _REL_?
mk/rte.sdkconfig.mk is not updated accordingly
(make showversion is broken)

[...]
>  #define RTE_VERSION RTE_VERSION_NUM( \
> -			RTE_VER_MAJOR, \
> -			RTE_VER_MINOR, \
> +			RTE_REL_YEAR, \
> +			RTE_REL_MONTH, \
>  			RTE_VER_PATCH_LEVEL, \
>  			RTE_VER_PATCH_RELEASE)

Is there a better name for RTE_VER_PATCH_LEVEL and RTE_VER_PATCH_RELEASE?
I think PATCH_LEVEL should be MINOR, i.e. the number increased when
doing some maintenance releases.
The last digit is useful for release candidates and non-official packaging
(downstream consumers like Linux distros or vendors). It should be updated
when delivering a patched DPDK version. RTE_VER_SUFFIX should also be updated
accordingly. So is RTE_VER_PATCH_RELEASE the right name? I guess yes but not
sure.

[...]
> +	if (RTE_VER_PATCH_LEVEL > 0)
> +		pos += snprintf(version + pos, sizeof(version) - pos, ".%d",
>  			RTE_VER_PATCH_LEVEL);

I disagree.
It's important to know that it is the first of the major release (.0).
I think we can remove it elsewhere. Example: PROJECT_NUMBER in doxygen.