Move room version spec to /rooms (#3423)

* Cut/paste room version spec to its own page

* Move grammar to bottom + add feature matrix

The version grammar is not as interesting as the actual room versions, so this moves that whole section to the bottom.

* Fix all links to room versions
This commit is contained in:
Travis Ralston 2021-10-12 14:47:03 -06:00 committed by GitHub
parent f295e828dc
commit 649fc2bdd2
No known key found for this signature in database
GPG key ID: 4AEE18F83AFDEB23
25 changed files with 152 additions and 145 deletions

View file

@ -93,7 +93,7 @@ should be followed where possible, if implementations decide to work ahead of sp
#### Room versions
When a new room version is needed, implementations MUST use vendor-prefixed versions
before using the namespace reserved for Matrix (see https://matrix.org/docs/spec/#room-versions).
before using the namespace reserved for Matrix (see https://spec.matrix.org/unstable/rooms/).
A room version is considered released once it is listed as an "available room version" in
the spec. Often a new room version is accompanied with a server-server API release, but
doesn't have to be.

View file

@ -113,10 +113,9 @@ room state can begin to drift, and the room can eventually become
not form part of the room state": we have a risk that some servers will accept
the event, and some will not.
One approach to solving this is via [room
versions](https://matrix.org/docs/spec/index#room-versions). By specifying that
a change of rules only applies for a future room version, we can eliminate this
potential disagreement.
One approach to solving this is via [room versions](https://spec.matrix.org/unstable/rooms/).
By specifying that a change of rules only applies for a future room version,
we can eliminate this potential disagreement.
The process of changing a room from one version to another is intrusive, not
least because it requires that all servers in a room support the new room

View file

@ -8,7 +8,7 @@ which apply:
that the client-server API currently ties the major version of its spec document version to the
endpoint, thus making most endpoints under it `/r0/` (currently).
3. Room versions which define a set of behaviour and algorithms on a per-room basis. These are well
defined in the spec and are not covered here: https://matrix.org/docs/spec/#room-versions
defined in the spec and are not covered here: https://spec.matrix.org/unstable/rooms/
4. An overarching "Matrix" version, largely for marketing purposes. So far we've only cut Matrix 1.0
back when we finalized the initial versions of the spec documents, but have not cut another one
since.