chore(docs): move deprecated platforms information around
We used to have a dedicated page for deprecated platforms information.
This document contained 2 pieces of information:
a) the process for deprecating a platform port;
b) the list of deprecated platforms to this day.
I think it makes more sense to move b) to the platforms ports landing
page, such that it is more visible.
This also has the nice effect to move the 'Deprecated platforms' title
as the last entry of the 'Platform ports' table of contents, like so:
- Platform ports
- 1. Allwinner ARMv8 SoCs
- 2. Arm Development Platforms
...
- 39. Broadcom Stingray
- Deprecated platforms
instead of it being lost in the middle of supported platform ports.
Regarding a), this gets moved under the "Processes & Policies" section.
More specifically, it gets clubbed with the existing platform
compatibility policy. The combined document gets renamed into a
"Platforms Ports Policy" document.
Change-Id: I6e9ce2abc68b8a8ac88e7bd5f21749c14c9a2af6
Signed-off-by: Sandrine Bailleux <sandrine.bailleux@arm.com>
diff --git a/docs/process/platform-ports-policy.rst b/docs/process/platform-ports-policy.rst
new file mode 100644
index 0000000..7983749
--- /dev/null
+++ b/docs/process/platform-ports-policy.rst
@@ -0,0 +1,51 @@
+Platform Ports Policy
+=====================
+
+This document clarifies a couple of policy points around platform ports
+management.
+
+Platform compatibility policy
+-----------------------------
+
+Platform compatibility is mainly affected by changes to Platform APIs (as
+documented in the :ref:`Porting Guide`), driver APIs (like the GICv3 drivers) or
+library interfaces (like xlat_table library). The project will try to maintain
+compatibility for upstream platforms. Due to evolving requirements and
+enhancements, there might be changes affecting platform compatibility which
+means the previous interface needs to be deprecated and a new interface
+introduced to replace it. In case the migration to the new interface is trivial,
+the contributor of the change is expected to make good effort to migrate the
+upstream platforms to the new interface.
+
+The deprecated interfaces are listed inside :ref:`Release Processes` as well as
+the release after which each one will be removed. When an interface is
+deprecated, the page must be updated to indicate the release after which the
+interface will be removed. This must be at least 1 full release cycle in future.
+For non-trivial interface changes, an email should be sent out to the `TF-A
+public mailing list`_ to notify platforms that they should migrate away from the
+deprecated interfaces. Platforms are expected to migrate before the removal of
+the deprecated interface.
+
+Platform deprecation policy
+---------------------------
+
+If a platform is no longer maintained, it is best to deprecate it to keep the
+projects' source tree clean and healthy. Deprecation can be a 1-stage or 2-stage
+process (up to the platform maintainers).
+
+ - *2-stage*: The platform's source code can be kept in the repository for a
+ cooling off period before deleting it (typically 2 release cycles). In this
+ case, we keep track ot the *Deprecated* version separately from the *Deleted*
+ version.
+
+ - *1-stage*: The platform's source code can be deleted straight away. In this
+ case, both versions are the same.
+
+The :ref:`Platform Ports` page provides a list of all deprecated/deleted
+platform ports (or soon to be) to this day.
+
+--------------
+
+*Copyright (c) 2018-2022, Arm Limited and Contributors. All rights reserved.*
+
+.. _TF-A public mailing list: https://lists.trustedfirmware.org/mailman3/lists/tf-a.lists.trustedfirmware.org/