From: Ferruh Yigit <ferruh.yigit@intel.com>
To: Kevin Traynor <ktraynor@redhat.com>,
dev@dpdk.org, John McNamara <john.mcnamara@intel.com>,
Marko Kovacevic <marko.kovacevic@intel.com>
Cc: Luca Boccassi <bluca@debian.org>,
Yongseok Koh <yskoh@mellanox.com>,
Neil Horman <nhorman@tuxdriver.com>
Subject: Re: [dpdk-dev] [PATCH v3 3/3] doc: add deprecation marker usage
Date: Thu, 24 Jan 2019 14:31:50 +0000 [thread overview]
Message-ID: <322d6651-3520-4c07-4bf2-e605da06f525@intel.com> (raw)
In-Reply-To: <bb2c1c5d-47d1-27a0-e5d8-a546a02bd4a2@redhat.com>
On 1/23/2019 11:07 PM, Kevin Traynor wrote:
> On 01/22/2019 05:23 PM, Ferruh Yigit wrote:
>> Define '__rte_deprecated' usage process.
>>
>> Suggests keeping old API with '__rte_deprecated' marker including
>> next LTS, they will be removed just after the LTS release.
>>
>> Signed-off-by: Ferruh Yigit <ferruh.yigit@intel.com>
>> Acked-by: Luca Boccassi <bluca@debian.org>
>> ---
>> Cc: Luca Boccassi <bluca@debian.org>
>> Cc: Kevin Traynor <ktraynor@redhat.com>
>> Cc: Yongseok Koh <yskoh@mellanox.com>
>> Cc: Neil Horman <nhorman@tuxdriver.com>
>>
>> v2:
>> * Rephrased as commented
>>
>> v3:
>> * changed when to remove the deprecated API. It is now just after
>> an LTS release, the motivation is to keep changes small in LTS.
>> Based on techboard discussion:
>> http://mails.dpdk.org/archives/dev/2019-January/123519.html
>> ---
>> doc/guides/contributing/versioning.rst | 9 +++++++++
>> 1 file changed, 9 insertions(+)
>>
>> diff --git a/doc/guides/contributing/versioning.rst b/doc/guides/contributing/versioning.rst
>> index bfc27fbe0..977d06c60 100644
>> --- a/doc/guides/contributing/versioning.rst
>> +++ b/doc/guides/contributing/versioning.rst
>> @@ -125,6 +125,15 @@ added to the Release Notes:
>> these changes. Binaries using this library built prior to version 2.1 will
>> require updating and recompilation.
>>
>> +New API replacing previous one
>> +~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
>> +
>> +If a new API proposed functionally replaces an existing one, when the
>> +new API becomes active then the old one is marked with ``__rte_deprecated``.
>
> I don't think it's clear what 'active' means here. Can it be re-phrased
> as something like "..when the new API has it's experimental tag removed,
> then the old one..".
This was what in my mind by 'active' but didn't want to create confusion with
details, and really it doesn't matter the "experimental" detail, by any means if
the new API is not 'active' we shouldn't mark the old one as 'deprecated'.
But agree can be defined better than 'active'. Do you have any suggestion here,
'GA', 'public', 'official', 'supported'?
>
> It might also be worth mentioning the reasoning behind this, perhaps
> something like: This is so an application continues to be provided with
> at least one stable (non-deprecated/non-experimental) API for this
> functionality.
>
>> +Deprecated APIs removed completely just after the next LTS.
>> +
>> +Reminder that new API should follow deprecation process to become active.
>> +
>>
>> Experimental APIs
>> -----------------
>>
>
next prev parent reply other threads:[~2019-01-24 14:31 UTC|newest]
Thread overview: 30+ messages / expand[flat|nested] mbox.gz Atom feed top
2018-12-19 12:52 [dpdk-dev] [RFC 1/2] doc: clean ABI/API policy guide Ferruh Yigit
2018-12-19 12:52 ` [dpdk-dev] [RFC 2/2] doc: add deprecation marker usage Ferruh Yigit
2018-12-20 8:02 ` Luca Boccassi
2018-12-21 15:52 ` Ferruh Yigit
2018-12-20 8:02 ` [dpdk-dev] [RFC 1/2] doc: clean ABI/API policy guide Luca Boccassi
2018-12-20 8:03 ` Luca Boccassi
2018-12-21 15:57 ` [dpdk-dev] [PATCH v2 " Ferruh Yigit
2018-12-21 15:57 ` [dpdk-dev] [PATCH v2 2/2] doc: add deprecation marker usage Ferruh Yigit
2019-01-22 16:23 ` [dpdk-dev] [PATCH v3 1/3] doc: clean ABI/API policy guide Ferruh Yigit
2019-01-22 16:23 ` [dpdk-dev] [PATCH v3 2/3] doc: make RTE_NEXT_ABI optional Ferruh Yigit
2019-01-22 16:23 ` [dpdk-dev] [PATCH v3 3/3] doc: add deprecation marker usage Ferruh Yigit
2019-01-23 23:07 ` Kevin Traynor
2019-01-24 14:31 ` Ferruh Yigit [this message]
2019-01-24 15:33 ` Kevin Traynor
2019-01-24 16:29 ` Ferruh Yigit
2019-01-23 8:13 ` [dpdk-dev] [PATCH v3 1/3] doc: clean ABI/API policy guide Neil Horman
2019-01-24 18:10 ` [dpdk-dev] [PATCH v4 " Ferruh Yigit
2019-01-24 18:10 ` [dpdk-dev] [PATCH v4 2/3] doc: make RTE_NEXT_ABI optional Ferruh Yigit
2019-01-31 17:18 ` Thomas Monjalon
2019-01-24 18:10 ` [dpdk-dev] [PATCH v4 3/3] doc: add deprecation marker usage Ferruh Yigit
2019-01-31 17:17 ` Thomas Monjalon
2019-02-01 17:06 ` Ferruh Yigit
2019-03-01 16:46 ` Thomas Monjalon
2019-01-31 17:46 ` [dpdk-dev] [PATCH v4 1/3] doc: clean ABI/API policy guide Kevin Traynor
2019-03-01 17:32 ` [dpdk-dev] [PATCH v5 " Ferruh Yigit
2019-03-01 17:32 ` [dpdk-dev] [PATCH v5 2/3] doc: make RTE_NEXT_ABI optional Ferruh Yigit
2019-03-01 17:32 ` [dpdk-dev] [PATCH v5 3/3] doc: add deprecation marker usage Ferruh Yigit
2019-03-01 17:40 ` Kevin Traynor
2019-03-27 13:29 ` Thomas Monjalon
2019-03-27 13:29 ` 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=322d6651-3520-4c07-4bf2-e605da06f525@intel.com \
--to=ferruh.yigit@intel.com \
--cc=bluca@debian.org \
--cc=dev@dpdk.org \
--cc=john.mcnamara@intel.com \
--cc=ktraynor@redhat.com \
--cc=marko.kovacevic@intel.com \
--cc=nhorman@tuxdriver.com \
--cc=yskoh@mellanox.com \
/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).