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

["Wiles, Keith" <keith.wiles@intel.com>]

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