Our process documentation already mentions that if a platform is no
longer maintained, it is best to deprecate it to keep the project's
source tree clean and healthy.
The same argument stands for drivers or library interfaces so extend
this policy to those.
Signed-off-by: Sandrine Bailleux <sandrine.bailleux@arm.com>
Change-Id: Ieb235d6a1fb089343e0e1e3e5f36067552f2f8f0
Clarify that downstream platforms generally do not affect code
deprecation / removal decisions.
Signed-off-by: Sandrine Bailleux <sandrine.bailleux@arm.com>
Change-Id: I44b979c4e67ee03537852769e96544e19137bda3
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>
2022-11-09 10:32:59 +01:00
Renamed from docs/process/platform-compatibility-policy.rst (Browse further)
