Syntax Compatibility Strategy document #251
Conversation
There was a problem hiding this comment.
Thanks for the update.
I have one more general thought, but not pressing right now: Should we be explicit about not allowing insta-break changes? I can see people wondering "Dude, I can also just break stuff, what's then?", might be good to make that explicit?
The only other thing I found was that it'd be nice to backport the changes you made to post 1.x at the bottom to the introduction part. I took a stab at that, feel free to put something else in there. Nothing blocking.
| Fluent implementation in the target project. Syntax newer than the upper bound | ||
| must not be allowed in the project's translations; 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. |
There was a problem hiding this comment.
Thanks for the em dash here. I could go with spaces around it, but I know that's debated spelling.
|
Thanks for the review, @Pike.
Let's work on adding this in a follow-up. Adding it won't contradict the overall tone of the document. |
This document is based on my conversations with @flodolo and @Pike. The goal is to document the compatibility strategy for introducing and removing syntax features.