Jonathan de Jong

Put `RoomVersionId`'s `PartialOrd` implementation behind a cargo feature

7

Per the spec; > There is no implicit ordering or hierarchy to room versions, and their principles are immutable once placed in the specification. Effectively, this would make any ordering...

[MSC](https://github.com/matrix-org/matrix-spec-proposals/pull/3754) Relevant endpoints; ```http DELETE /_matrix/client/v1/profile/{userId}/avatar_url DELETE /_matrix/client/v1/profile/{userId}/displayname ``` Unstable variants; ```http DELETE /_matrix/client/unstable/org.matrix.msc3754/profile/{userId}/avatar_url DELETE /_matrix/client/unstable/org.matrix.msc3754/profile/{userId}/displayname ```

https://github.com/matrix-org/matrix-doc/pull/3743 This may be interesting to implement in a potential ruma-axum crate.

Duplicated pusher types

2

While going through `client_api::r0::push`, between `get_pushers`, `set_pusher`, and such, i noticed a *ton* of duplication between pusher types, with the only difference being that one of them allows creation of...

Find a nicer way to do `ruma-api-macros::Request::path_fields_ordered`

1

https://github.com/ruma/ruma/pull/900 introduced `path_fields_ordered`, which, while correct, looks like the following; https://github.com/ruma/ruma/blob/f72d6601fcf2ce4382a7c02b740d60a6e803f4d9/crates/ruma-api-macros/src/request.rs#L167-L188 I think one possible way to make this nicer is to add a `get_path_field Option

Decide on how to detect v1.0

4

https://github.com/ruma/ruma/issues/840 describes adding and detecting v1.0 via parsing `"r0.6.1"` and friends, however, the spec is a bit ambiguous on what exactly "counts" as v1.0, as it gives a table of...

Possibly add `legacy` path definitions to metadata

1

https://github.com/ruma/ruma/issues/842 introduces `stable`, `r0`, and `unstable`, the three most common path definitions for endpoints (canonically without r0, but included for legacy purposes) We may discover that there exists additional path...

Integrate "MSC feature tracking" in xtask

2

We seem to want to use the `unstable-msc1234` format, but i think that its hard to keep track of all of it manually, so i think xtask should be expanded...

This is a bikeshed issue, sprung from #840; Basically, I'd like to make it easy for applications to decide on a "maximum operating matrix version", the matrix version their application...

Statically verify ruma routes with the spec's openapi docs

1

Mainly for methods and (maybe) paths, as https://github.com/ruma/ruma/commit/a39bee994985ae2ba05c317edac4a32764aa5492 kinda shows, it could help somewhat with verifying that everything is a-okay.