Filip/matrix-spec
1
0
Fork 0
mirror of https://github.com/matrix-org/matrix-spec synced 2026-01-05 23:43:43 +01:00
Code Issues Actions 3 Packages Projects Releases Wiki Activity

Apply suggestions from code review

Browse source 
Co-Authored-By: Richard van der Hoff <1389908+richvdh@users.noreply.github.com>
This commit is contained in:
Travis Ralston 2020-03-05 17:24:29 -07:00 committed by GitHub
parent 3ee9a7d654
commit da795e5824
No known key found for this signature in database
GPG key ID: 4AEE18F83AFDEB23
1 changed files with 3 additions and 3 deletions
Show stats Download patch file Download diff file Expand all files Collapse all files

6
specification/proposals_intro.rst
View file

@ -385,14 +385,14 @@ The process for an implementation willing to be ahead of a spec release is:
* When using this approach correctly, the implementation can ship/release the
feature at any time, so long as the implementation is able to accept the technical
debt that results from needing to provide adequate backwards and forwards
compatibility. The implementation MUST support the flag disappearing and be
compatibility. The implementation MUST support the flag (and server-side implementation) disappearing and be
generally safe for users. Note that implementations early in the MSC review
process may also be required to provide backwards compatibility with earlier
editions of the proposal.
* If the implementation cannot support the technical debt (or if it's impossible
to provide forwards/backwards compatibility - e.g. a user authentication change
which can't be safely rolled back), the implementation should not attempt to
implement the feature and instead wait for a spec release.
implement the feature and should instead wait for a spec release.
* If at any point the idea changes, the feature flag should also change so that
implementations can adapt as needed.
@ -429,7 +429,7 @@ The process for an implementation willing to be ahead of a spec release is:
In summary:
* Implementations MUST NOT use stable endpoints before the MSC is in the spec. This
includes NOT using stable endpoints before a spec release happens, but after FCP has
includes NOT using stable endpoints in the period between completion of FCP and release of the spec.
passed.
* Implementations are able to ship features that are exposed to users by default before
an MSC has been merged to the spec, provided they follow the process above.