|
|
@ -7,7 +7,7 @@ which apply:
|
|
|
|
2. Individual endpoint versioning underneath an API spec document version (`/v1/`, `/v2/`, etc). Note
|
|
|
|
2. Individual endpoint versioning underneath an API spec document version (`/v1/`, `/v2/`, etc). Note
|
|
|
|
that the client-server API currently ties the major version of its spec document version to the
|
|
|
|
that the client-server API currently ties the major version of its spec document version to the
|
|
|
|
endpoint, thus making most endpoints under it as `/r0/` (currently).
|
|
|
|
endpoint, thus making most endpoints under it as `/r0/` (currently).
|
|
|
|
3. Room versions to freezing a set of behaviour and algorithms on a per-room basis. These are well
|
|
|
|
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://matrix.org/docs/spec/#room-versions
|
|
|
|
4. An overarching "Matrix" version, largely for marketing purposes. So far we've only cut Matrix 1.0
|
|
|
|
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
|
|
|
|
back when we finalized the initial versions of the spec documents, but have not cut another one
|
|
|
@ -29,9 +29,9 @@ it currently), the APIs, room versions, and the appendices (which are also curre
|
|
|
|
contain specification). Room versions are a bit more nuanced though, and are covered later in this MSC.
|
|
|
|
contain specification). Room versions are a bit more nuanced though, and are covered later in this MSC.
|
|
|
|
|
|
|
|
|
|
|
|
The version which covers the entire specification and all its parts is called the "Matrix version", and
|
|
|
|
The version which covers the entire specification and all its parts is called the "Matrix version", and
|
|
|
|
is a promotion of the previously marketing-only version number assigned to the spec. Upon acceptance of
|
|
|
|
is a promotion of the previously marketing-only version number assigned to the spec. The spec core team
|
|
|
|
this MSC, the Matrix version would be 1.1.0. v1.0 from the marketing era would be recorded somewhere for
|
|
|
|
is expected to release Matrix 1.1.0 as the first version, leaving v1.0 as the marketing era and recorded
|
|
|
|
posterity, though largely has no significant meaning (unchanged by this MSC).
|
|
|
|
somewhere for posterity (though has no significant meaning, unchanged by this MSC).
|
|
|
|
|
|
|
|
|
|
|
|
Doing this has the benefits previously alluded to:
|
|
|
|
Doing this has the benefits previously alluded to:
|
|
|
|
|
|
|
|
|
|
|
@ -66,10 +66,10 @@ Given a version number `MAJOR.MINOR.PATCH`, incremement the:
|
|
|
|
When present in the protocol itself, the Matrix version will always be prefixed with `v`. For example,
|
|
|
|
When present in the protocol itself, the Matrix version will always be prefixed with `v`. For example,
|
|
|
|
`v1.1.0`.
|
|
|
|
`v1.1.0`.
|
|
|
|
|
|
|
|
|
|
|
|
When a dash (`-`) is present after the `PATCH` version, the version is denoting some off-cycle release
|
|
|
|
Additional information can be supplied in the version number by appending a dash (`-`) to the end of the
|
|
|
|
information. This is how we'd, for example, make release candidates, alpha, beta, or unstable builds as
|
|
|
|
version and including any relevant information. This is typically used to denote alpha, beta, unstable,
|
|
|
|
needed. This MSC does not propose a scheme for RCs or pre-releases, though the Spec Core Team may wish
|
|
|
|
or other similar off-cycle release builds. This MSC does not propose a scheme for RCs or pre-releases,
|
|
|
|
to do so.
|
|
|
|
though the Spec Core Team may wish to do so.
|
|
|
|
|
|
|
|
|
|
|
|
See the section on brewing Matrix versions for information on how the unstable version is decided.
|
|
|
|
See the section on brewing Matrix versions for information on how the unstable version is decided.
|
|
|
|
|
|
|
|
|
|
|
@ -158,7 +158,7 @@ the Spec Core Team be able to blindside the community with a release for no just
|
|
|
|
|
|
|
|
|
|
|
|
To recap, the process is as follows:
|
|
|
|
To recap, the process is as follows:
|
|
|
|
|
|
|
|
|
|
|
|
1. Sometime after a given release happens, the Spec Core Team announces a cutoff date for MSCs to land
|
|
|
|
1. Sometime before a given release happens, the Spec Core Team announces a cutoff date for MSCs to land
|
|
|
|
that is at least 2 months in the future.
|
|
|
|
that is at least 2 months in the future.
|
|
|
|
2. Upon cutoff, the Spec Core Team takes responsibility for ensuring all relevant changes are written
|
|
|
|
2. Upon cutoff, the Spec Core Team takes responsibility for ensuring all relevant changes are written
|
|
|
|
up in a timely fashion.
|
|
|
|
up in a timely fashion.
|
|
|
|