2015-12-18 20:12, Wiles, Keith:
> On 12/18/15, 1:50 PM, "O'Driscoll, Tim" <tim.odriscoll at intel.com> wrote:
>
> >
> >> -----Original Message-----
> >> From: dev [mailto:dev-bounces at dpdk.org] On Behalf Of Wiles, Keith
> >> Sent: Friday, December 18, 2015 7:23 PM
> >> To: Thomas Monjalon; Richardson, Bruce
> >> Cc: dev at 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 at dpdk.org on behalf of thomas.monjalon at 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 at 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
