-----Original Message-----
From: dev [mailto:dev-bounces@dpdk.org] On Behalf Of Wiles, Keith
Sent: Friday, December 18, 2015 7:23 PM
To: Thomas Monjalon; Richardson, Bruce
Cc: dev@dpdk.org
Subject: Re: [dpdk-dev] [PATCH 1/2] version: 2.3.0-rc0

On 12/18/15, 10:11 AM, "dev on behalf of Thomas Monjalon" <dev-
bounces@dpdk.org on behalf of thomas.monjalon@6wind.com> wrote:

quoted

2015-12-18 12:11, Bruce Richardson:

quoted

On Thu, Dec 17, 2015 at 12:16:30PM +0100, Thomas Monjalon wrote:

quoted

Signed-off-by: Thomas Monjalon <redacted>
---
 lib/librte_eal/common/include/rte_version.h | 6 +++---
 1 file changed, 3 insertions(+), 3 deletions(-)

diff --git a/lib/librte_eal/common/include/rte_version.h

b/lib/librte_eal/common/include/rte_version.h

quoted

quoted

quoted

index bb3e9fc..6b1890e 100644

--- a/lib/librte_eal/common/include/rte_version.h
+++ b/lib/librte_eal/common/include/rte_version.h

@@ -60,7 +60,7 @@ extern "C" {
 /**
  * Minor version number i.e. the y in x.y.z
  */
-#define RTE_VER_MINOR 2
+#define RTE_VER_MINOR 3

 /**
  * Patch level number i.e. the z in x.y.z

@@ -70,14 +70,14 @@ extern "C" {
 /**
  * Extra string to be appended to version number
  */
-#define RTE_VER_SUFFIX ""
+#define RTE_VER_SUFFIX "-rc"

 /**
  * Patch release number
  *   0-15 = release candidates
  *   16   = release
  */
-#define RTE_VER_PATCH_RELEASE 16
+#define RTE_VER_PATCH_RELEASE 0

 /**
  * Macro to compute a version number usable for comparisons

What about the discussion about the numbering of DPDK versions in

future? The

quoted

quoted

latest suggest which was +1'ed a number of times was to use an

Ubuntu-style

quoted

quoted

YY.MM naming scheme. I don't think there was any objections to such a

scheme

quoted

quoted

so is it not premature to start naming the new release now using the

old scheme?

quoted

Before doing any change on master, it is better to change the version

number

quoted

to avoid confusion with the previous release. Example, the generated

doc does

quoted

not show 2.2 anymore.

About changing the numbering, no problem, it can be changed at any time

before

quoted

the RC1. At the moment there was a proposal for YY.MM and a proposal

for 3.0.

quoted

Even the YY.MM needs more discussion as it is not clear if we should

use 15.03

quoted

or 15.04 for the release ending at the end of March. It seems

reasonnable to

quoted

expect a release the next day, i.e. in April.

I believe the numbering should be 16.03, 16.06, 16.09 and 16.12. As for
2.2.0 we should give it a second name 15.12 == 2.2.0 (and add a label in
Git), then we can start with 16.03 as the next release number. All
efforts should be made to meet the months 3, 6, 9 and 12, if one happens
to be into the next month for some reason then we still label and call
it the correct release number.

When you say "the correct release number" I think you mean that if a release is planned for March but is actually completed in April, it would still be called 16.03. I believe Ubuntu take the opposite approach, and if a release does slip it gets the number for the month it's actually completed in (16.04 in this example). There are advantages and disadvantages to both approaches. We'll need to decide which approach is best.

The best way to avoid confusion it to move from planning releases for the end of a month to planning them for the start of a month. So, as Thomas suggested above, we shouldn't plan our next release for the end of March, but for the start of April instead. That way it becomes 16.04, and we have a month of leeway in case there is a slip.

I would also suggest we label the 15.12 release as the Long Term Support
(LTS), just to get a base line for the LTS. Then every 2 years(??) we
have a new LTS release next one on 17.12, ...

+1 on this.


Tim

Keith

quoted

Regards,
Keith