DPDK patches and discussions
 help / color / mirror / Atom feed
From: Ferruh Yigit <ferruh.yigit@intel.com>
To: dev@dpdk.org, John McNamara <john.mcnamara@intel.com>,
	Marko Kovacevic <marko.kovacevic@intel.com>
Cc: Neil Horman <nhorman@tuxdriver.com>,
	Luca Boccassi <bluca@debian.org>,
	Kevin Traynor <ktraynor@redhat.com>,
	Yongseok Koh <yskoh@mellanox.com>
Subject: [dpdk-dev] [PATCH v5 2/3] doc: make RTE_NEXT_ABI optional
Date: Fri,  1 Mar 2019 17:32:49 +0000	[thread overview]
Message-ID: <20190301173250.80930-2-ferruh.yigit@intel.com> (raw)
In-Reply-To: <20190301173250.80930-1-ferruh.yigit@intel.com>

Initial process requires oncoming changes described in deprecation
notice should be implemented in a RTE_NEXT_ABI gated way.

This has been discussed in technical board, and since this can cause a
multiple #ifdef blocks in multiple locations of the code, can be
confusing specially for the modifications that requires data structure
changes. Anyway this was not happening in practice.

Making RTE_NEXT_ABI usage more optional based on techboard decision:
http://mails.dpdk.org/archives/dev/2019-January/123519.html

The intention with using RTE_NEXT_ABI was to provide more information
to the user about planned changes, and force developer to think more in
coding level. Since RTE_NEXT_ABI become optional, now the preferred way
to do this is, if possible, sending changes, described in deprecation
notice, as a separate patch and reference it in deprecation notice.

Signed-off-by: Ferruh Yigit <ferruh.yigit@intel.com>
Acked-by: Neil Horman <nhorman@tuxdriver.com>
---
Cc: Luca Boccassi <bluca@debian.org>
Cc: Kevin Traynor <ktraynor@redhat.com>
Cc: Yongseok Koh <yskoh@mellanox.com>
Cc: Neil Horman <nhorman@tuxdriver.com>
---
 doc/guides/contributing/versioning.rst | 15 ++++++---------
 1 file changed, 6 insertions(+), 9 deletions(-)

diff --git a/doc/guides/contributing/versioning.rst b/doc/guides/contributing/versioning.rst
index 0bd7e6c44..2fcb8bafd 100644
--- a/doc/guides/contributing/versioning.rst
+++ b/doc/guides/contributing/versioning.rst
@@ -73,19 +73,16 @@ being provided. The requirements for doing so are:
      interest" be sought for each deprecation, for example: from NIC vendors,
      CPU vendors, end-users, etc.
 
-#. The changes (including an alternative map file) must be gated with
-   the ``RTE_NEXT_ABI`` option, and provided with a deprecation notice at the
-   same time.
-   It will become the default ABI in the next release.
+#. The changes (including an alternative map file) can be included with
+   deprecation notice, in wrapped way by the ``RTE_NEXT_ABI`` option,
+   to provide more details about oncoming changes.
+   ``RTE_NEXT_ABI`` wrapper will be removed when it become the default ABI.
+   More preferred way to provide this information is sending the feature
+   as a separate patch and reference it in deprecation notice.
 
 #. A full deprecation cycle, as explained above, must be made to offer
    downstream consumers sufficient warning of the change.
 
-#. At the beginning of the next release cycle, every ``RTE_NEXT_ABI``
-   conditions will be removed, the ``LIBABIVER`` variable in the makefile(s)
-   where the ABI is changed will be incremented, and the map files will
-   be updated.
-
 Note that the above process for ABI deprecation should not be undertaken
 lightly. ABI stability is extremely important for downstream consumers of the
 DPDK, especially when distributed in shared object form. Every effort should
-- 
2.20.1

  reply	other threads:[~2019-03-01 17:32 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
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         ` Ferruh Yigit [this message]
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=20190301173250.80930-2-ferruh.yigit@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).