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