[dpdk-dev] [PATCH 1/2] version: 2.3.0-rc0

[dpdk-dev] [PATCH 1/2] version: 2.3.0-rc0

[Thomas Monjalon]

Signed-off-by: Thomas Monjalon <thomas.monjalon@6wind.com>
---
 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
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
-- 
2.5.2

[dpdk-dev] [PATCH 2/2] doc: init next release notes

[Thomas Monjalon]

Signed-off-by: Thomas Monjalon <thomas.monjalon@6wind.com>
---
 doc/guides/rel_notes/index.rst       |  1 +
 doc/guides/rel_notes/release_2_3.rst | 76 ++++++++++++++++++++++++++++++++++++
 2 files changed, 77 insertions(+)
 create mode 100644 doc/guides/rel_notes/release_2_3.rst

diff --git a/doc/guides/rel_notes/index.rst b/doc/guides/rel_notes/index.rst
index e633e13..29013cf 100644
--- a/doc/guides/rel_notes/index.rst
+++ b/doc/guides/rel_notes/index.rst
@@ -36,6 +36,7 @@ Release Notes
     :numbered:
 
     rel_description
+    release_2_3
     release_2_2
     release_2_1
     release_2_0
diff --git a/doc/guides/rel_notes/release_2_3.rst b/doc/guides/rel_notes/release_2_3.rst
new file mode 100644
index 0000000..99de186
--- /dev/null
+++ b/doc/guides/rel_notes/release_2_3.rst
@@ -0,0 +1,76 @@
+DPDK Release 2.3
+================
+
+New Features
+------------
+
+
+Resolved Issues
+---------------
+
+EAL
+~~~
+
+
+Drivers
+~~~~~~~
+
+
+Libraries
+~~~~~~~~~
+
+
+Examples
+~~~~~~~~
+
+
+Other
+~~~~~
+
+
+Known Issues
+------------
+
+
+API Changes
+-----------
+
+
+ABI Changes
+-----------
+
+
+Shared Library Versions
+-----------------------
+
+The libraries prepended with a plus sign were incremented in this version.
+
+.. code-block:: diff
+
+     libethdev.so.2
+     librte_acl.so.2
+     librte_cfgfile.so.2
+     librte_cmdline.so.1
+     librte_distributor.so.1
+     librte_eal.so.2
+     librte_hash.so.2
+     librte_ip_frag.so.1
+     librte_ivshmem.so.1
+     librte_jobstats.so.1
+     librte_kni.so.2
+     librte_kvargs.so.1
+     librte_lpm.so.2
+     librte_mbuf.so.2
+     librte_mempool.so.1
+     librte_meter.so.1
+     librte_pipeline.so.2
+     librte_pmd_bond.so.1
+     librte_pmd_ring.so.2
+     librte_port.so.2
+     librte_power.so.1
+     librte_reorder.so.1
+     librte_ring.so.1
+     librte_sched.so.1
+     librte_table.so.2
+     librte_timer.so.1
+     librte_vhost.so.2
-- 
2.5.2

Re: [dpdk-dev] [PATCH 2/2] doc: init next release notes

[Mcnamara, John]

> -----Original Message-----
> From: Thomas Monjalon [mailto:thomas.monjalon@6wind.com]
> Sent: Thursday, December 17, 2015 11:17 AM
> To: Mcnamara, John
> Cc: dev@dpdk.org
> Subject: [PATCH 2/2] doc: init next release notes
> 
> Signed-off-by: Thomas Monjalon <thomas.monjalon@6wind.com>

Acked-by: John McNamara <john.mcnamara@intel.com>

Re: [dpdk-dev] [PATCH 1/2] version: 2.3.0-rc0

[Thomas Monjalon]

> > Signed-off-by: Thomas Monjalon <thomas.monjalon@6wind.com>
> 
> Acked-by: John McNamara <john.mcnamara@intel.com>

Series applied, thanks

Re: [dpdk-dev] [PATCH 1/2] version: 2.3.0-rc0

[Bruce Richardson]

On Thu, Dec 17, 2015 at 12:16:30PM +0100, Thomas Monjalon wrote:
> Signed-off-by: Thomas Monjalon <thomas.monjalon@6wind.com>
> ---
>  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
> 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
> -- 
> 2.5.2
> 

What about the discussion about the numbering of DPDK versions in future? The
latest suggest which was +1'ed a number of times was to use an Ubuntu-style
YY.MM naming scheme. I don't think there was any objections to such a scheme
so is it not premature to start naming the new release now using the old scheme?

/Bruce

Re: [dpdk-dev] [PATCH 1/2] version: 2.3.0-rc0

[Thomas Monjalon]

2015-12-18 12:11, Bruce Richardson:
> On Thu, Dec 17, 2015 at 12:16:30PM +0100, Thomas Monjalon wrote:
> > Signed-off-by: Thomas Monjalon <thomas.monjalon@6wind.com>
> > ---
> >  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
> > 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
> latest suggest which was +1'ed a number of times was to use an Ubuntu-style
> YY.MM naming scheme. I don't think there was any objections to such a scheme
> so is it not premature to start naming the new release now using the old scheme?

Before doing any change on master, it is better to change the version number
to avoid confusion with the previous release. Example, the generated doc does
not show 2.2 anymore.

About changing the numbering, no problem, it can be changed at any time before
the RC1. At the moment there was a proposal for YY.MM and a proposal for 3.0.
Even the YY.MM needs more discussion as it is not clear if we should use 15.03
or 15.04 for the release ending at the end of March. It seems reasonnable to
expect a release the next day, i.e. in April.

Re: [dpdk-dev] [PATCH 1/2] version: 2.3.0-rc0

[Wiles, Keith]

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:

>2015-12-18 12:11, Bruce Richardson:
>> On Thu, Dec 17, 2015 at 12:16:30PM +0100, Thomas Monjalon wrote:
>> > Signed-off-by: Thomas Monjalon <thomas.monjalon@6wind.com>
>> > ---
>> >  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
>> > 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
>> latest suggest which was +1'ed a number of times was to use an Ubuntu-style
>> YY.MM naming scheme. I don't think there was any objections to such a scheme
>> so is it not premature to start naming the new release now using the old scheme?
>
>Before doing any change on master, it is better to change the version number
>to avoid confusion with the previous release. Example, the generated doc does
>not show 2.2 anymore.
>
>About changing the numbering, no problem, it can be changed at any time before
>the RC1. At the moment there was a proposal for YY.MM and a proposal for 3.0.
>Even the YY.MM needs more discussion as it is not clear if we should use 15.03
>or 15.04 for the release ending at the end of March. It seems reasonnable to
>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.

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, ...

Keith
>


Regards,
Keith

Re: [dpdk-dev] [PATCH 1/2] version: 2.3.0-rc0

[O'Driscoll, Tim]

> -----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:
> 
> >2015-12-18 12:11, Bruce Richardson:
> >> On Thu, Dec 17, 2015 at 12:16:30PM +0100, Thomas Monjalon wrote:
> >> > Signed-off-by: Thomas Monjalon <thomas.monjalon@6wind.com>
> >> > ---
> >> >  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
> >> > 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
> >> latest suggest which was +1'ed a number of times was to use an
> Ubuntu-style
> >> YY.MM naming scheme. I don't think there was any objections to such a
> scheme
> >> so is it not premature to start naming the new release now using the
> old scheme?
> >
> >Before doing any change on master, it is better to change the version
> number
> >to avoid confusion with the previous release. Example, the generated
> doc does
> >not show 2.2 anymore.
> >
> >About changing the numbering, no problem, it can be changed at any time
> before
> >the RC1. At the moment there was a proposal for YY.MM and a proposal
> for 3.0.
> >Even the YY.MM needs more discussion as it is not clear if we should
> use 15.03
> >or 15.04 for the release ending at the end of March. It seems
> reasonnable to
> >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
> >
> 
> 
> Regards,
> Keith
> 
> 
> 

Re: [dpdk-dev] [PATCH 1/2] version: 2.3.0-rc0

[Wiles, Keith]

On 12/18/15, 1:50 PM, "O'Driscoll, Tim" <tim.odriscoll@intel.com> wrote:

>
>> -----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:
>> 
>> >2015-12-18 12:11, Bruce Richardson:
>> >> On Thu, Dec 17, 2015 at 12:16:30PM +0100, Thomas Monjalon wrote:
>> >> > Signed-off-by: Thomas Monjalon <thomas.monjalon@6wind.com>
>> >> > ---
>> >> >  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
>> >> > 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
>> >> latest suggest which was +1'ed a number of times was to use an
>> Ubuntu-style
>> >> YY.MM naming scheme. I don't think there was any objections to such a
>> scheme
>> >> so is it not premature to start naming the new release now using the
>> old scheme?
>> >
>> >Before doing any change on master, it is better to change the version
>> number
>> >to avoid confusion with the previous release. Example, the generated
>> doc does
>> >not show 2.2 anymore.
>> >
>> >About changing the numbering, no problem, it can be changed at any time
>> before
>> >the RC1. At the moment there was a proposal for YY.MM and a proposal
>> for 3.0.
>> >Even the YY.MM needs more discussion as it is not clear if we should
>> use 15.03
>> >or 15.04 for the release ending at the end of March. It seems
>> reasonnable to
>> >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.

I just figured keeping the number the release number as expected was the best. I do not remember Ubuntu release numbers not on 4 or 10, but I could wrong. Most likely moving the release date to the first of the month is the right solution anyway. The only problem with 16.04 or April 1st is April fools day, but it really is not a big problem as long as we do not call it April 1st only YY.04.
>
>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 guess the release numbers would be 16.04, 16.07, 16.10 and then 17.01, 17.04, 17.07, 17.10 which is fine. I just liked the 3, 6, 9, 12 number scheme multiple of 3. If we stick with 3,6,9,12 and 16.03 release date would be 2016.03.01 for the first of the month. The next release after 15.12 will be a short release cycle and we get to keep the multiple of 3. :-)

Plus with the end of year stuff it would be best to start a release on Dec 1st then on Jan 1st, right?
>
>> 
>> 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
>> >
>> 
>> 
>> Regards,
>> Keith
>> 
>> 
>> 
>
>


Regards,
Keith

Re: [dpdk-dev] [PATCH 1/2] version: 2.3.0-rc0

[Thomas Monjalon]

2015-12-18 20:12, Wiles, Keith:
> On 12/18/15, 1:50 PM, "O'Driscoll, Tim" <tim.odriscoll@intel.com> wrote:
> 
> >
> >> -----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:
> >> 
> >> >2015-12-18 12:11, Bruce Richardson:
> >> >> On Thu, Dec 17, 2015 at 12:16:30PM +0100, Thomas Monjalon wrote:
> >> >> > Signed-off-by: Thomas Monjalon <thomas.monjalon@6wind.com>
> >> >> > ---
> >> >> >  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
> >> >> > 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
> >> >> latest suggest which was +1'ed a number of times was to use an
> >> Ubuntu-style
> >> >> YY.MM naming scheme. I don't think there was any objections to such a
> >> scheme
> >> >> so is it not premature to start naming the new release now using the
> >> old scheme?
> >> >
> >> >Before doing any change on master, it is better to change the version
> >> number
> >> >to avoid confusion with the previous release. Example, the generated
> >> doc does
> >> >not show 2.2 anymore.
> >> >
> >> >About changing the numbering, no problem, it can be changed at any time
> >> before
> >> >the RC1. At the moment there was a proposal for YY.MM and a proposal
> >> for 3.0.
> >> >Even the YY.MM needs more discussion as it is not clear if we should
> >> use 15.03
> >> >or 15.04 for the release ending at the end of March. It seems
> >> reasonnable to
> >> >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.
> 
> I just figured keeping the number the release number as expected was the best. I do not remember Ubuntu release numbers not on 4 or 10, but I could wrong. Most likely moving the release date to the first of the month is the right solution anyway. The only problem with 16.04 or April 1st is April fools day, but it really is not a big problem as long as we do not call it April 1st only YY.04.
> >
> >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 guess the release numbers would be 16.04, 16.07, 16.10 and then 17.01, 17.04, 17.07, 17.10 which is fine. I just liked the 3, 6, 9, 12 number scheme multiple of 3. If we stick with 3,6,9,12 and 16.03 release date would be 2016.03.01 for the first of the month. The next release after 15.12 will be a short release cycle and we get to keep the multiple of 3. :-)
> 
> Plus with the end of year stuff it would be best to start a release on Dec 1st then on Jan 1st, right?

It is the wrong thread to discuss it.
In the right thread, you would see that the scheduling is a bit different:
	http://dpdk.org/ml/archives/dev/2015-December/030123.html