mirror of
https://github.com/luau-lang/rfcs.git
synced 2025-04-01 17:10:58 +01:00
Update README.md
This commit is contained in:
parent
70871e7516
commit
f71a7c5578
1 changed files with 2 additions and 0 deletions
|
@ -40,6 +40,8 @@ When the initial comment period expires, the RFC can be merged if there's consen
|
|||
|
||||
When revisions on the RFC text that affect syntax/semantics are suggested, they need to be incorporated before a RFC is merged; a merged RFC represents a maximally accurate version of the language change that is going to be implemented.
|
||||
|
||||
Each RFC will be assigned a shepherd. This person will support you in getting feedback, request necessary changes, and ultimately either accept (and merge) the RFC or turn it away.
|
||||
|
||||
In some cases RFCs may contain conditional compatibility clauses. E.g. there are cases where a change is potentially not backwards compatible, but is believed to be substantially beneficial that it can be implemented if, in practice, the backwards compatibility implications are minimal. As a strawman example, if we wanted to introduce a non-context-specific keyword `globallycoherent`, we would be able to do so if our analysis of Luau code (based on the Roblox platform at the moment) informs us that no script in existence uses this keyword. In cases like this an RFC may need to be revised after the initial implementation attempt based on the data that we gather.
|
||||
|
||||
In general, RFCs can also be updated after merging to make the language of the RFC more clear, but should not change their meaning. When a new feature is built on top of an existing feature that has an RFC, a new RFC should be created instead of editing an existing RFC.
|
||||
|
|
Loading…
Add table
Reference in a new issue