From: Thomas Monjalon <thomas.monjalon@6wind.com>
To: Bruce Richardson <bruce.richardson@intel.com>
Cc: dev@dpdk.org
Subject: Re: [dpdk-dev] [PATCH 2/3] version: adjust printing for new version scheme
Date: Mon, 28 Dec 2015 23:25:10 +0100 [thread overview]
Message-ID: <7956038.7RoB3127Jy@xps13> (raw)
In-Reply-To: <1450704384-9986-3-git-send-email-bruce.richardson@intel.com>
2015-12-21 13:26, Bruce Richardson:
> Since we are now using a year-month numbering scheme, adjust
> the printing of the version to always use 2-digits for YY.MM
> format.
Yes
It must be done for "make showversion" also.
> Also omit the patch version unless there is a patch version present,
> since patches for releases are rare on DPDK. This means that the
> final release of 16.04 will report as 16.04, rather than 16.04.0.
So the numbering of master and maintenance releases will not be consistent:
16.04 and then 16.04.1
It's true that maintenance releases are rare but it has been discussed at
Dublin to have ones in future.
So are we OK to omit the .0 even if not consistent?
> Release candidates for it will similarly report as 16.04-rcX.
Yes, 16.04-rcX looks nicer than 16.04.0-rcX.
Shouldn't we take the opportunity to update RTE_VER_PREFIX from
"RTE" to "DPDK"?
> /**
> * Major version number i.e. the x in x.y.z
> */
> -#define RTE_VER_MAJOR 16
> +#define RTE_REL_YEAR 16
>
> /**
> * Minor version number i.e. the y in x.y.z
> */
> -#define RTE_VER_MINOR 4
> +#define RTE_REL_MONTH 4
Why renaming from _VER_ to _REL_?
mk/rte.sdkconfig.mk is not updated accordingly
(make showversion is broken)
[...]
> #define RTE_VERSION RTE_VERSION_NUM( \
> - RTE_VER_MAJOR, \
> - RTE_VER_MINOR, \
> + RTE_REL_YEAR, \
> + RTE_REL_MONTH, \
> RTE_VER_PATCH_LEVEL, \
> RTE_VER_PATCH_RELEASE)
Is there a better name for RTE_VER_PATCH_LEVEL and RTE_VER_PATCH_RELEASE?
I think PATCH_LEVEL should be MINOR, i.e. the number increased when
doing some maintenance releases.
The last digit is useful for release candidates and non-official packaging
(downstream consumers like Linux distros or vendors). It should be updated
when delivering a patched DPDK version. RTE_VER_SUFFIX should also be updated
accordingly. So is RTE_VER_PATCH_RELEASE the right name? I guess yes but not
sure.
[...]
> + if (RTE_VER_PATCH_LEVEL > 0)
> + pos += snprintf(version + pos, sizeof(version) - pos, ".%d",
> RTE_VER_PATCH_LEVEL);
I disagree.
It's important to know that it is the first of the major release (.0).
I think we can remove it elsewhere. Example: PROJECT_NUMBER in doxygen.
next prev parent reply other threads:[~2015-12-28 22:26 UTC|newest]
Thread overview: 16+ messages / expand[flat|nested] mbox.gz Atom feed top
2015-12-21 13:26 [dpdk-dev] [PATCH 0/3] switch to using YY.MM version numbers Bruce Richardson
2015-12-21 13:26 ` [dpdk-dev] [PATCH 1/3] version: switch to year/month " Bruce Richardson
2016-02-10 14:33 ` [dpdk-dev] [PATCH v2 1/2] " John McNamara
2016-02-10 14:33 ` [dpdk-dev] [PATCH v2 2/2] doc: rename release notes 2.3 to 16.04 John McNamara
2016-02-10 15:11 ` [dpdk-dev] [PATCH v2 1/2] version: switch to year/month version numbers Thomas Monjalon
2016-02-10 15:31 ` Bruce Richardson
2016-02-10 16:52 ` Mcnamara, John
2015-12-21 13:26 ` [dpdk-dev] [PATCH 2/3] version: adjust printing for new version scheme Bruce Richardson
2015-12-28 22:25 ` Thomas Monjalon [this message]
2016-02-10 14:28 ` Mcnamara, John
2015-12-21 13:26 ` [dpdk-dev] [PATCH 3/3] doc: rename release 2.3 to 16.04 Bruce Richardson
2016-02-10 17:02 ` [dpdk-dev] [PATCH v3 1/2] version: switch to year/month version numbers John McNamara
2016-02-10 17:02 ` [dpdk-dev] [PATCH v3 2/2] doc: rename release notes 2.3 to 16.04 John McNamara
2016-02-10 17:11 ` [dpdk-dev] [PATCH v3 1/2] version: switch to year/month version numbers Mcnamara, John
2016-02-10 17:20 ` Thomas Monjalon
2016-02-10 21:49 ` 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=7956038.7RoB3127Jy@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).