Add stability policy (#472)

* Add stability policy

* Apply suggestions from code review

* Apply suggestions from code review

* Update spec/README.md

Co-authored-by: Addison Phillips <[email protected]>

* style: Apply Prettier

* Update spec/README.md

Co-authored-by: Stanisław Małolepszy <[email protected]>

* Apply suggestions from code review

Co-authored-by: Stanisław Małolepszy <[email protected]>

* Add note about formatters potentially changing

Co-authored-by: Mark Davis <[email protected]>

* Update spec/README.md

* style: Apply Prettier

---------

Co-authored-by: Addison Phillips <[email protected]>
Co-authored-by: github-actions[bot] <41898282+github-actions[bot]@users.noreply.github.com>
Co-authored-by: Stanisław Małolepszy <[email protected]>
Co-authored-by: Mark Davis <[email protected]>

Author: 5 people

spec/README.md

@@ -5,6 +5,7 @@
 1. [Introduction](#introduction)
    1. [Conformance](#conformance)
    1. [Terminology and Conventions](#terminology-and-conventions)
+   1. [Stability Policy](#stability-policy)
 1. [Syntax](syntax.md)
    1. [Productions](syntax.md#productions)
    1. [Tokens](syntax.md#tokens)
@@ -66,3 +67,47 @@ A **_term_** looks like this when it is defined in this specification.
 A reference to a _term_ looks like this.
 
 > Examples are non-normative and styled like this.
+
+### Stability Policy
+
+Updates to this specification MUST NOT change
+the syntactical meaning, the runtime output, or other behaviour
+of valid messages written for earlier versions of this specification
+that only use functions and expression attributes defined in this specification.
+Updates to this specification will not remove any syntax provided
+in this version. Future versions MAY add additional structure or meaning
+to existing syntax.
+
+Updates to this specification will not remove any reserved keywords
+or sigils.
+
+> Note: future versions may defined new keywords
+
+Updates to this specification will not reserve or assign meaning to any
+character "sigils" except for those in the `reserved` production.
+
+Updates to this specification will not remove any functions
+defined in the default registry nor will they remove any options
+or option values. Additional options or option values MAY be
+defined.
+
+> [!NOTE]
+> This does not guarantee that the results of formatting will never change.
+> Even when the specification doesn't change,
+> the functions for date formatting, number formatting and so on
+> will change their results over time.
+
+Updates to this specification MUST NOT introduce message syntax that,
+when parsed according to earlier versions of this specification,
+would produce syntax or data model errors.
+Such messages MAY produce errors when formatted
+according to an earlier version of this specification.
+
+From version 2.0, MessageFormat will only reserve, define, or require
+function names or function option names
+consisting of characters in the ranges a-z, A-Z, and 0-9.
+All other names in these categories are reserved for the use of implementations or users.
+
+> [!NOTE]
+> Users defining custom names SHOULD include at least one character outside these ranges
+> to ensure that they will be compatible with future versions of this specification.