Checks
Commit Message
Start version numbering for a new release cycle,
and introduce a template file for release notes.
The release notes comments are updated to mandate
a scope label for API and ABI changes.
Signed-off-by: Thomas Monjalon <thomas@monjalon.net>
---
doc/guides/rel_notes/index.rst | 1 +
doc/guides/rel_notes/release_19_02.rst | 209 ++++++++++++++++++++
lib/librte_eal/common/include/rte_version.h | 8 +-
meson.build | 2 +-
4 files changed, 215 insertions(+), 5 deletions(-)
create mode 100644 doc/guides/rel_notes/release_19_02.rst
Comments
On 11/28/2018 10:44 AM, Thomas Monjalon wrote:
> Start version numbering for a new release cycle,
> and introduce a template file for release notes.
>
> The release notes comments are updated to mandate
> a scope label for API and ABI changes.
>
> Signed-off-by: Thomas Monjalon <thomas@monjalon.net>
> ---
> doc/guides/rel_notes/index.rst | 1 +
> doc/guides/rel_notes/release_19_02.rst | 209 ++++++++++++++++++++
What do you think about storing the release notes template in git repo, this
helps creating new ones for next release also makes easier to track/view what
has been changed in the release notes template?
Reviewed-by: Ferruh Yigit <ferruh.yigit@intel.com>
28/11/2018 12:16, Ferruh Yigit:
> On 11/28/2018 10:44 AM, Thomas Monjalon wrote:
> > Start version numbering for a new release cycle,
> > and introduce a template file for release notes.
> >
> > The release notes comments are updated to mandate
> > a scope label for API and ABI changes.
> >
> > Signed-off-by: Thomas Monjalon <thomas@monjalon.net>
> > ---
> > doc/guides/rel_notes/index.rst | 1 +
> > doc/guides/rel_notes/release_19_02.rst | 209 ++++++++++++++++++++
>
> What do you think about storing the release notes template in git repo, this
> helps creating new ones for next release also makes easier to track/view what
> has been changed in the release notes template?
If something is changed in the release notes, it should be updated
in the template, with a risk of forgetting.
And the list of libraries would need to be updated too.
I feel it would be more complications.
> -----Original Message-----
> From: Thomas Monjalon [mailto:thomas@monjalon.net]
> Sent: Wednesday, November 28, 2018 10:45 AM
> To: dev@dpdk.org
> Cc: Mcnamara, John <john.mcnamara@intel.com>; Kovacevic, Marko
> <marko.kovacevic@intel.com>
> Subject: [PATCH] version: 19.02-rc0
Acked-by: John McNamara <john.mcnamara@intel.com>
On 11/28/2018 12:45 PM, Thomas Monjalon wrote:
> 28/11/2018 12:16, Ferruh Yigit:
>> On 11/28/2018 10:44 AM, Thomas Monjalon wrote:
>>> Start version numbering for a new release cycle,
>>> and introduce a template file for release notes.
>>>
>>> The release notes comments are updated to mandate
>>> a scope label for API and ABI changes.
>>>
>>> Signed-off-by: Thomas Monjalon <thomas@monjalon.net>
>>> ---
>>> doc/guides/rel_notes/index.rst | 1 +
>>> doc/guides/rel_notes/release_19_02.rst | 209 ++++++++++++++++++++
>>
>> What do you think about storing the release notes template in git repo, this
>> helps creating new ones for next release also makes easier to track/view what
>> has been changed in the release notes template?
>
> If something is changed in the release notes, it should be updated
> in the template, with a risk of forgetting.
> And the list of libraries would need to be updated too.
> I feel it would be more complications.
OK, I see the concern.
What about doing rc0 release notes in two patches:
1- Copy-paste from previous release notes, strip the context.
2- Update the template as desired.
Overall I think this is good to have, if you think this is just extra overhead,
forget about it.
Thanks,
ferruh
28/11/2018 14:24, Ferruh Yigit:
> On 11/28/2018 12:45 PM, Thomas Monjalon wrote:
> > 28/11/2018 12:16, Ferruh Yigit:
> >> On 11/28/2018 10:44 AM, Thomas Monjalon wrote:
> >>> Start version numbering for a new release cycle,
> >>> and introduce a template file for release notes.
> >>>
> >>> The release notes comments are updated to mandate
> >>> a scope label for API and ABI changes.
> >>>
> >>> Signed-off-by: Thomas Monjalon <thomas@monjalon.net>
> >>> ---
> >>> doc/guides/rel_notes/index.rst | 1 +
> >>> doc/guides/rel_notes/release_19_02.rst | 209 ++++++++++++++++++++
> >>
> >> What do you think about storing the release notes template in git repo, this
> >> helps creating new ones for next release also makes easier to track/view what
> >> has been changed in the release notes template?
> >
> > If something is changed in the release notes, it should be updated
> > in the template, with a risk of forgetting.
> > And the list of libraries would need to be updated too.
> > I feel it would be more complications.
>
> OK, I see the concern.
>
> What about doing rc0 release notes in two patches:
> 1- Copy-paste from previous release notes, strip the context.
It is not only strip the context, I change version number
and add back the removed section.
> 2- Update the template as desired.
>
> Overall I think this is good to have, if you think this is just extra overhead,
> forget about it.
I understand you want to track the changes done in the template.
I will send a v2 with changes split.
@@ -8,6 +8,7 @@ Release Notes
:maxdepth: 1
:numbered:
+ release_19_02
release_18_11
release_18_08
release_18_05
new file mode 100644
@@ -0,0 +1,209 @@
+.. SPDX-License-Identifier: BSD-3-Clause
+ Copyright 2018 The DPDK contributors
+
+DPDK Release 19.02
+==================
+
+.. **Read this first.**
+
+ The text in the sections below explains how to update the release notes.
+
+ Use proper spelling, capitalization and punctuation in all sections.
+
+ Variable and config names should be quoted as fixed width text:
+ ``LIKE_THIS``.
+
+ Build the docs and view the output file to ensure the changes are correct::
+
+ make doc-guides-html
+
+ xdg-open build/doc/html/guides/rel_notes/release_19_02.html
+
+
+New Features
+------------
+
+.. This section should contain new features added in this release.
+ Sample format:
+
+ * **Add a title in the past tense with a full stop.**
+
+ Add a short 1-2 sentence description in the past tense.
+ The description should be enough to allow someone scanning
+ the release notes to understand the new feature.
+
+ If the feature adds a lot of sub-features you can use a bullet list
+ like this:
+
+ * Added feature foo to do something.
+ * Enhanced feature bar to do something else.
+
+ Refer to the previous release notes for examples.
+
+ Suggested order in release notes items:
+ * Core libs (EAL, mempool, ring, mbuf, buses)
+ * Device abstraction libs and PMDs
+ - ethdev (lib, PMDs)
+ - cryptodev (lib, PMDs)
+ - eventdev (lib, PMDs)
+ - etc
+ * Other libs
+ * Apps, Examples, Tools (if significant)
+
+ This section is a comment. Do not overwrite or remove it.
+ Also, make sure to start the actual text at the margin.
+ =========================================================
+
+
+Removed Items
+-------------
+
+.. This section should contain removed items in this release. Sample format:
+
+ * Add a short 1-2 sentence description of the removed item
+ in the past tense.
+
+ This section is a comment. Do not overwrite or remove it.
+ Also, make sure to start the actual text at the margin.
+ =========================================================
+
+
+API Changes
+-----------
+
+.. This section should contain API changes. Sample format:
+
+ * sample: Add a short 1-2 sentence description of the API change.
+ Start with a scope label like "ethdev:".
+ Use fixed width quotes for ``function_names`` or ``struct_names``.
+ Use the past tense.
+
+ This section is a comment. Do not overwrite or remove it.
+ Also, make sure to start the actual text at the margin.
+ =========================================================
+
+
+ABI Changes
+-----------
+
+.. This section should contain ABI changes. Sample format:
+
+ * sample: Add a short 1-2 sentence description of the ABI change.
+ Start with a scope label like "ethdev:".
+ that was announced in the previous releases and made in this release.
+ Use fixed width quotes for ``function_names`` or ``struct_names``.
+ Use the past tense.
+
+ This section is a comment. Do not overwrite or remove it.
+ Also, make sure to start the actual text at the margin.
+ =========================================================
+
+
+Shared Library Versions
+-----------------------
+
+.. Update any library version updated in this release
+ and prepend with a ``+`` sign, like this:
+
+ libfoo.so.1
+ + libupdated.so.2
+ libbar.so.1
+
+ This section is a comment. Do not overwrite or remove it.
+ =========================================================
+
+The libraries prepended with a plus sign were incremented in this version.
+
+.. code-block:: diff
+
+ librte_acl.so.2
+ librte_bbdev.so.1
+ librte_bitratestats.so.2
+ librte_bpf.so.1
+ librte_bus_dpaa.so.2
+ librte_bus_fslmc.so.2
+ librte_bus_ifpga.so.2
+ librte_bus_pci.so.2
+ librte_bus_vdev.so.2
+ librte_bus_vmbus.so.2
+ librte_cfgfile.so.2
+ librte_cmdline.so.2
+ librte_compressdev.so.1
+ librte_cryptodev.so.5
+ librte_distributor.so.1
+ librte_eal.so.9
+ librte_efd.so.1
+ librte_ethdev.so.11
+ librte_eventdev.so.6
+ librte_flow_classify.so.1
+ librte_gro.so.1
+ librte_gso.so.1
+ librte_hash.so.2
+ librte_ip_frag.so.1
+ librte_jobstats.so.1
+ librte_kni.so.2
+ librte_kvargs.so.1
+ librte_latencystats.so.1
+ librte_lpm.so.2
+ librte_mbuf.so.4
+ librte_member.so.1
+ librte_mempool.so.5
+ librte_meter.so.2
+ librte_metrics.so.1
+ librte_net.so.1
+ librte_pci.so.1
+ librte_pdump.so.2
+ librte_pipeline.so.3
+ librte_pmd_bnxt.so.2
+ librte_pmd_bond.so.2
+ librte_pmd_i40e.so.2
+ librte_pmd_ixgbe.so.2
+ librte_pmd_dpaa2_qdma.so.1
+ librte_pmd_ring.so.2
+ librte_pmd_softnic.so.1
+ librte_pmd_vhost.so.2
+ librte_port.so.3
+ librte_power.so.1
+ librte_rawdev.so.1
+ librte_reorder.so.1
+ librte_ring.so.2
+ librte_sched.so.1
+ librte_security.so.1
+ librte_table.so.3
+ librte_timer.so.1
+ librte_vhost.so.4
+
+
+Known Issues
+------------
+
+.. This section should contain new known issues in this release. Sample format:
+
+ * **Add title in present tense with full stop.**
+
+ Add a short 1-2 sentence description of the known issue
+ in the present tense. Add information on any known workarounds.
+
+ This section is a comment. Do not overwrite or remove it.
+ Also, make sure to start the actual text at the margin.
+ =========================================================
+
+
+Tested Platforms
+----------------
+
+.. This section should contain a list of platforms that were tested
+ with this release.
+
+ The format is:
+
+ * <vendor> platform with <vendor> <type of devices> combinations
+
+ * List of CPU
+ * List of OS
+ * List of devices
+ * Other relevant details...
+
+ This section is a comment. Do not overwrite or remove it.
+ Also, make sure to start the actual text at the margin.
+ =========================================================
@@ -27,12 +27,12 @@ extern "C" {
/**
* Major version/year number i.e. the yy in yy.mm.z
*/
-#define RTE_VER_YEAR 18
+#define RTE_VER_YEAR 19
/**
* Minor version/month number i.e. the mm in yy.mm.z
*/
-#define RTE_VER_MONTH 11
+#define RTE_VER_MONTH 2
/**
* Patch level number i.e. the z in yy.mm.z
@@ -42,14 +42,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_RELEASE 16
+#define RTE_VER_RELEASE 0
/**
* Macro to compute a version number usable for comparisons
@@ -2,7 +2,7 @@
# Copyright(c) 2017 Intel Corporation
project('DPDK', 'C',
- version: '18.11.0',
+ version: '19.02.0-rc0'
license: 'BSD',
default_options: ['buildtype=release', 'default_library=static'],
meson_version: '>= 0.41'