mirror of
https://github.com/ARM-software/arm-trusted-firmware.git
synced 2025-04-16 09:34:18 +00:00
347609510e
Currently links between documents are using the format: <path/to/><filename>.rst This was required for services like GitHub because they render each document in isolation - linking to another document is like linking to any other file, just provide the full path. However, with the new approach, the .rst files are only the raw source for the documents. Once the documents have been rendered the output is now in another format (HTML in our case) and so, when linking to another document, the link must point to the rendered version and not the .rst file. The RST spec provides a few methods for linking between content. The parent of this patch enabled the automatic creation of anchors for document titles - we will use these anchors as the targets for our links. Additional anchors can be added by hand if needed, on section and sub-section titles, for example. An example of this new format, for a document with the title "Firmware Design" is :ref:`Firmware Design`. One big advantage of this is that anchors are not dependent on paths. We can then move documents around, even between directories, without breaking any links between documents. Links will need to be updated only if the title of a document changes. Change-Id: I9e2340a61dd424cbd8fd1ecc2dc166f460d81703 Signed-off-by: Paul Beesley <paul.beesley@arm.com>
36 lines
1.6 KiB
ReStructuredText
36 lines
1.6 KiB
ReStructuredText
Platform Compatibility Policy
|
|
=============================
|
|
|
|
Introduction
|
|
------------
|
|
|
|
This document clarifies the project's policy around compatibility for upstream
|
|
platforms.
|
|
|
|
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.
|
|
|
|
--------------
|
|
|
|
*Copyright (c) 2018-2019, Arm Limited and Contributors. All rights reserved.*
|
|
|
|
.. _TF-A public mailing list: https://lists.trustedfirmware.org/mailman/listinfo/tf-a
|