Address review 1

spec/compatibility.md

@@ -13,16 +13,16 @@ primary purposes:
 ## Types of Changes
 
 _Backwards incompatible_ changes make old files not parse in the current
-parsers. Removing a feature which was previously available and reporting a
-`SyntaxError` instead is a backwards incompatible change.
+parsers. Removing a feature which was previously available and reporting
+a `SyntaxError` instead is a backwards incompatible change.
 
-_Extensions_ are changes which introduce syntax which was previously
-forbidden. They make current files with the extended syntax not parse in old
+_Extensions_ are changes which introduce syntax which was previously forbidden.
+Extensions make current files with the extended syntax not parse in old
 parsers. Old files continue to parse correctly in the current parsers.
 
 _Deprecations_ are non-breaking changes meant to encourage the use of more
 modern syntax and guarantee a transition period for migrating translations to
-the modern syntax. They may herald future removals of syntax features.
+the modern syntax. Deprecations herald future removals of syntax features.
 
 
 ## The 1.x
@@ -33,13 +33,16 @@ must maintain backwards compatibility with 1.0.
 The dot releases may introduce new syntax in a backwards compatible way. New
 features are only allowed as extensions to the 1.0 syntax and the AST.
 
-Extensions may be accompanied by deprecations. Deprecated syntax will
-continue to be supported throughout the 1.x lifetime. Parsers will report
-deprecations as `Annotations` in the `SyntaxNode.annotations` field.
-Authoring tools should encourage translators to use the new syntax. They are
-free to choose the length of the grace period by configuring which
-deprecations should be considered as errors, depending on the currently-used
-Fluent implementation in the target project.
+Extensions may be accompanied by deprecations. Deprecated syntax will continue
+to be supported throughout the 1.x lifetime. Parsers will report deprecations
+as annotations in the AST.
+
+Authoring tools should provide per-project settings for specifying the lower
+and upper bounds of accepted syntax versions, depending on the currently-used
+Fluent implementation in the target project. Syntax newer than the upper bound
+must not be allowed. Syntax deprecated in versions older than the lower bound
+should be reported as warnings, and later on, as errors, depending on the grace
+period chosen for the project.
 
 
 ## The 2.0
@@ -51,23 +54,21 @@ release with all deprecations removed.
 We’re developing Fluent with a future standard in mind. Fluent 2.0 will be a
 stepping stone towards it, achieving the following goals.
 
-  - Trimming deprecated features is an opportunity to establish a fresh
-    baseline for subsequent Fluent 2.x releases and the future standard.
+  - Establish a fresh baseline for subsequent Fluent 2.x releases and the
+    future standard by trimming deprecated features.
 
-  - It will improve the learnability of Fluent by reducing the cognitive
+  - Improve the learnability of Fluent by reducing the cognitive
     complexity of the syntax.
 
-  - Finally, it will allow implementations to streamline their codebases,
-    which can increase their quality and give opportunities for new performance
-    optimizations.
-
-To help the users transition to 2.0, we’ll create a tool, `fluent1to2`, for
-performing a one-time migration from 1.x to 2.0. This tool would use the last
-stable version of the 1.x parser and would force the serialization of the
-deprecated syntax using the more modern alternatives, if possible.
+  - Allow implementations to streamline their codebases, which can increase
+    their quality and give opportunities for new performance optimizations.
 
 
 ## The 2.x and Beyond
 
-The dot releases in the 2.x lifetime will follow the same rules as 1.x. The
-3.0 will follow the same rules as 2.0.
+The dot releases in the 2.x lifetime will follow the same rules as 1.x. If
+there are compelling reasons to publish them, the subsequent major releases
+(3.0, 4.0, etc.) may be breaking ones; they will follow the same rules as 2.0.
+
+If Fluent succeeds as a future standard, the compatibility strategy will be
+decided by the standards organization publishing it.