9aa47b86c4
The "Room Specification" (or "Room Version Specification") is the specification that defines which room versions do what and are intended to be documents which speak the truth about how rooms operate under the hood. The approach taken here is a bit different than other specifications. For starters, the specification is versioned in this project instead of relying on the matrix.org repository to track compiled HTML. This is done for a couple reasons, the first being we're still developing the v1 specification while concurrently making a v2 spec and the second being trying to reduce the reliance on matrix.org's repository for specifications. Because the room spec is built into versions, some changes needed to be made. The `targets.yaml` now has a special syntax for indicating what version something is at, and the changelog generator can handle rendering different versions of the same changelog (as parsed from the RST). Some additional work has been put in to the changelog parsing to allow us to reference the v1 room spec as "v1" without having to sacrifice clarity in the changelog headings. Finally, this moves the identifier grammar as it stands into the v1 room spec. This is in anticipation of the v2 room spec having a different set of grammar. Event schemas haven't been migrated here while the MSC to change them is in-flight. There are a few open questions at this point: * Do we move state resolution into here? * Do we move the auth rules into here? Note: this does not introduce the concept of versioned schemas (tabs) that I was previously working with. There's currently no use for them, so they are shelved elsewhere. |
||
|---|---|---|
| .. | ||
| application_service | ||
| client_server | ||
| identity_service | ||
| push_gateway | ||
| rooms | ||
| server_server | ||
| README.md | ||
| application_service.rst | ||
| client_server.rst | ||
| identity_service.rst | ||
| push_gateway.rst | ||
| rooms.rst | ||
| server_server.rst | ||
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
- Ensure you're in your Python 3 virtual environment
cdyour way to the API you're releasing (eg:cd changelogs/client_server)- Run
towncrier --version "r0.4.0" --name "client-server" --yessubstituting the variables as approprite. Note that--nameis required although the value is ignored. - 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.
- Create the file
changelogs/server_server.rst - Create the folder
changelogs/server_server - In the new folder, create a
pyproject.tomlfile 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 - Create a
.gitignoreinchangelogs/server_server/newsfragmentswith the contents!.gitignore