From: Thomas Monjalon <thomas.monjalon@6wind.com>
To: Bruce Richardson <bruce.richardson@intel.com>
Cc: dev@dpdk.org
Subject: Re: [dpdk-dev] [PATCH 1/2] version: 2.3.0-rc0
Date: Fri, 18 Dec 2015 17:11:33 +0100 [thread overview]
Message-ID: <1561631.aijrKaNmiP@xps13> (raw)
In-Reply-To: <20151218121145.GB11116@bricha3-MOBL3>
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.
next prev parent reply other threads:[~2015-12-18 16:12 UTC|newest]
Thread overview: 10+ messages / expand[flat|nested] mbox.gz Atom feed top
2015-12-17 11:16 Thomas Monjalon
2015-12-17 11:16 ` [dpdk-dev] [PATCH 2/2] doc: init next release notes Thomas Monjalon
2015-12-17 14:40 ` Mcnamara, John
[not found] ` <B27915DBBA3421428155699D51E4CFE2024090EB@IRSMSX103.ger.corp.intel.com>
2015-12-17 15:04 ` [dpdk-dev] [PATCH 1/2] version: 2.3.0-rc0 Thomas Monjalon
2015-12-18 12:11 ` Bruce Richardson
2015-12-18 16:11 ` Thomas Monjalon [this message]
2015-12-18 19:22 ` Wiles, Keith
2015-12-18 19:50 ` O'Driscoll, Tim
2015-12-18 20:12 ` Wiles, Keith
2015-12-18 20:43 ` Thomas Monjalon
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=1561631.aijrKaNmiP@xps13 \
--to=thomas.monjalon@6wind.com \
--cc=bruce.richardson@intel.com \
--cc=dev@dpdk.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).