README: Relocate elaboration on stabilisation
Make it less prominent so it doesn't distract from the earlier
discussion.
Change-Id: I90cff245cec8d39ab7d85388526829ee6f0345e3
Signed-off-by: Andrew Jeffery <andrew@codeconstruct.com.au>
diff --git a/README.md b/README.md
index d944782..a6c5c58 100644
--- a/README.md
+++ b/README.md
@@ -72,25 +72,6 @@
required functions fall into the deprecated or testing categories is outlined
below.
-### What does it mean to mark a function as stable?
-
-Marking a function as stable makes the following promise to users of the
-library:
-
-> We will not remove or change the symbol name, argument count, argument types,
-> return type, or interpretation of relevant values for the function before
-> first marking it as `LIBPLDM_ABI_DEPRECATED` and then subsequently creating a
-> tagged release
-
-Marking a function as stable does _not_ promise that it is free of
-implementation bugs. It is just a promise that the prototype won't change
-without notice.
-
-Given this, it is always okay to implement functions marked stable in terms of
-functions marked testing inside of libpldm. If we remove or change the prototype
-of a function marked testing the only impact is that we need to fix up any call
-sites of that function in the same patch.
-
### The ABI lifecycle
```mermaid
@@ -162,10 +143,26 @@
}
```
-### Requirements for stabilising a function
+### What does it mean to mark a function as stable?
-As mentioned above, all new functions must first be added in the testing
-category (using the `LIBPLDM_ABI_TESTING` annotation).
+Marking a function as stable makes the following promise to users of the
+library:
+
+> We will not remove or change the symbol name, argument count, argument types,
+> return type, or interpretation of relevant values for the function before
+> first marking it as `LIBPLDM_ABI_DEPRECATED` and then subsequently creating a
+> tagged release
+
+Marking a function as stable does _not_ promise that it is free of
+implementation bugs. It is just a promise that the prototype won't change
+without notice.
+
+Given this, it is always okay to implement functions marked stable in terms of
+functions marked testing inside of libpldm. If we remove or change the prototype
+of a function marked testing the only impact is that we need to fix up any call
+sites of that function in the same patch.
+
+### Requirements for stabilising a function
To move a function from the testing category to the stable category, it's
required that patches demonstrating use of the function in a dependent