Filip/matrix-spec
1
0
Fork 0
mirror of https://github.com/matrix-org/matrix-spec synced 2025-12-24 09:58:38 +01:00
Code Issues Actions 1 Packages Projects Releases Wiki Activity
matrix-spec/changelogs
History
Jimmy Cuadra bc71dacaf4 Clarify the distinction between *m.key.verification.start* and its *m.sas.v1* variant. 
Currently the *m.key.verification.start* event appears twice with the
exact same title, in the "Key verification framework" section and the
"Short Authentication (SAS) verification" section. It's not immediately
clear that the first occurrence describes the format of the event in
general terms and that the second occurrence describes the fields when
the *m.sas.v1* verification method is being used. This is a similar
relationship to the *m.room.message* event and its various *msgtype*
variants.

This commit does three things:

* It tweaks the generation of the documentation to change the title
  of the second occurrence of *m.key.verification.start* to
  distinguish it from the first.
* It updates the language in the description of the two versions of the
  event to better describe the relationship between the two.
* It adds the optional `next_method` field to the schema of the
  *m.sas.v1* variant, as specified in the general form of
  *m.key.verification.start*.

Signed-off-by: Jimmy Cuadra <jimmy@jimmycuadra.com>
2019-06-14 16:20:51 -07:00
..
application_service Appservice r0.1.1 2019-06-11 10:15:51 -06:00
client_server Clarify the distinction between *m.key.verification.start* and its *m.sas.v1* variant. 2019-06-14 16:20:51 -07:00
identity_service Merge pull request #2126 from matrix-org/travis/403-id-unbind 2019-06-13 06:25:28 -06:00
push_gateway r0.1.0 release of the Push Gateway specification 2018-08-16 11:50:18 -06:00
server_server Federation r0.1.2 2019-06-11 10:38:12 -06:00
application_service.rst Appservice r0.1.1 2019-06-11 10:15:51 -06:00
client_server.rst Client-Server r0.5.0 2019-06-11 10:40:48 -06:00
identity_service.rst Identity r0.2.0 2019-06-11 10:30:56 -06:00
push_gateway.rst r0.1.0 release of the Push Gateway specification 2018-08-16 11:50:18 -06:00
README.md Don't let the newsfragments wink out of existence 2018-07-06 17:32:57 -06:00
server_server.rst Federation r0.1.2 2019-06-11 10:38:12 -06:00

README.md

Changelogs

Towncrier is used to manage the changelog and keep it up to date. Because of this, updating a changelog is really easy.

How to update a changelog when releasing an API

  1. Ensure you're in your Python 3 virtual environment
  2. cd your way to the API you're releasing (eg: cd changelogs/client_server)
  3. Run towncrier --version "r0.4.0" --name "client-server" --yes substituting the variables as approprite. Note that --name is required although the value is ignored.
  4. Commit the changes and finish the release process.

How to prepare a changelog for a new API

For this example, we're going to pretend that the server_server API doesn't exist.

  1. Create the file changelogs/server_server.rst
  2. Create the folder changelogs/server_server
  3. In the new folder, create a pyproject.toml file with these contents: 
    [tool.towncrier]
 filename = "../server_server.rst"
 directory = "newsfragments"
 issue_format = "`#{issue} <https://github.com/matrix-org/matrix-doc/issues/{issue}>`_"
 title_format = "{version}"

 [[tool.towncrier.type]]
     directory = "breaking"
     name = "Breaking Changes"
     showcontent = true

 [[tool.towncrier.type]]
     directory = "deprecation"
     name = "Deprecations"
     showcontent = true

 [[tool.towncrier.type]]
     directory = "new"
     name = "New Endpoints"
     showcontent = true

 [[tool.towncrier.type]]
     directory = "feature"
     name = "Backwards Compatible Changes"
     showcontent = true

 [[tool.towncrier.type]]
     directory = "clarification"
     name = "Spec Clarifications"
     showcontent = true
  4. Create a .gitignore in changelogs/server_server/newsfragments with the contents !.gitignore