Re: [dpdk-dev] [PATCH] doc: add template release notes for 18.08

[Ferruh Yigit <ferruh.yigit@intel.com>]

On 6/5/2018 1:36 PM, Shreyansh Jain wrote:
> Hello Ferruh,
> 
>> -----Original Message-----
>> From: Ferruh Yigit [mailto:ferruh.yigit@intel.com]
>> Sent: Tuesday, June 5, 2018 2:34 PM
>> To: Thomas Monjalon <thomas@monjalon.net>; dev@dpdk.org
>> Cc: john.mcnamara@intel.com; marko.kovacevic@intel.com; Hemant Agrawal
>> <hemant.agrawal@nxp.com>; Shreyansh Jain <shreyansh.jain@nxp.com>
>> Subject: Re: [dpdk-dev] [PATCH] doc: add template release notes for
>> 18.08
>>
>> On 5/31/2018 10:11 PM, Thomas Monjalon wrote:
>>> Add template release notes for DPDK 18.08 with inline
>>> comments and explanations of the various sections.
>>>
>>> Signed-off-by: Thomas Monjalon <thomas@monjalon.net>
>>
>> <...>
>>
>>> +Shared Library Versions
>>> +-----------------------
>>> +
>>> +.. Update any library version updated in this release
>>> +   and prepend with a ``+`` sign, like this:
>>> +
>>> +     librte_acl.so.2
>>> +   + librte_cfgfile.so.2
>>> +     librte_cmdline.so.2
>>> +
>>> +   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_bus_dpaa.so.1
>>> +     librte_bus_fslmc.so.1
>>> +     librte_bus_pci.so.1
>>> +     librte_bus_vdev.so.1
>> <..>
>>> +     librte_common_octeontx.so.1
>> <..>
>>> +     librte_pmd_dpaa2_cmdif.so.1
> 
> cmdif doesn't expose any APIs for the user. It works through the librawdev APIs.
> 
> drivers/raw/dpaa2_cmdif/± cat rte_pmd_dpaa2_cmdif_version.map
> DPDK_18.05 {
> 
> 	local: *;
> };
> 
>>> +     librte_pmd_dpaa2_qdma.so.1
> 
> QDMA driver indeed exposes various APIs for the user/application.
> 
>>
>> Is above libraries provide any API for user application?
>>
>> It looks like they are for other internal libraries, if so should we
>> document
>> them here in release notes?
> 
> You are suggesting that we add a note stating a particular library has no exposed APIs? I can't guess what use that information would be for a release note reader.
> That might be a note for the relevant documentation rst file, though.

I suggest removing the library from release notes if it is only for internal
interface. Why user should concerned about version updates if the library is
internal only?

> 
>>
>> Thanks,
>> ferruh