You cannot select more than 25 topics Topics must start with a letter or number, can include dashes ('-') and can be up to 35 characters long.
matrix-spec-proposals/changelogs
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>
5 years ago
..
application_service Appservice r0.1.1 5 years ago
client_server Clarify the distinction between *m.key.verification.start* and its *m.sas.v1* variant. 5 years ago
identity_service Merge pull request #2126 from matrix-org/travis/403-id-unbind 5 years ago
push_gateway r0.1.0 release of the Push Gateway specification 6 years ago
server_server Federation r0.1.2 5 years ago
README.md Don't let the newsfragments wink out of existence 6 years ago
application_service.rst Appservice r0.1.1 5 years ago
client_server.rst Client-Server r0.5.0 5 years ago
identity_service.rst Identity r0.2.0 5 years ago
push_gateway.rst r0.1.0 release of the Push Gateway specification 6 years ago
server_server.rst Federation r0.1.2 5 years ago

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