doc: add note on hardware support deprecation

Following agreement at the DPDK Technical Board meeting [1], the policy
that hardware support deprecation should be treated as though it were an
ABI break needs to be documented in the contributors guide.

[1] http://dpdk.org/ml/archives/dev/2017-September/074613.html

Signed-off-by: Bruce Richardson <bruce.richardson@intel.com>
Acked-by: John McNamara <john.mcnamara@intel.com>

diff --git a/doc/guides/contributing/versioning.rst b/doc/guides/contributing/versioning.rst
index 8aaf370..8d0fdb7 100644 (file)
--- a/doc/guides/contributing/versioning.rst
+++ b/doc/guides/contributing/versioning.rst
@@ -18,6 +18,8 @@ General Guidelines
 #. The modification of symbols can generally be managed with versioning
 #. The removal of symbols generally is an ABI break and requires bumping of the
    LIBABIVER macro
 #. The modification of symbols can generally be managed with versioning
 #. The removal of symbols generally is an ABI break and requires bumping of the
    LIBABIVER macro

+#. Updates to the minimum hardware requirements, which drop support for hardware which
+   was previously supported, should be treated as an ABI change.

 
 What is an ABI
 --------------
 
 What is an ABI
 --------------


@@ -77,6 +79,13 @@ for significant reasons, such as performance enhancements. ABI breakage due to
 changes such as reorganizing public structure fields for aesthetic or
 readability purposes should be avoided.
 
 changes such as reorganizing public structure fields for aesthetic or
 readability purposes should be avoided.
 

+.. note::
+
+   Updates to the minimum hardware requirements, which drop support for hardware
+   which was previously supported, should be treated as an ABI change, and
+   follow the relevant deprecation policy procedures as above: 3 acks and
+   announcement at least one release in advance.
+

 Examples of Deprecation Notices
 -------------------------------
 
 Examples of Deprecation Notices
 -------------------------------