| 9 Jan 2020 |
 tulir | yeah I thought it's the endpoint version rather than weird-whole-spec-but-not-really version | 19:26:51 |
 TravisR | !github create "Actually document the vX versioning scheme" "Probably under the 'specification versions' on the index where rX is specified. Is it the endpoint version or iteration of the spec?" | 19:28:21 |
 Github | Created issue: https://github.com/matrix-org/matrix-doc/issues/2404 | 19:28:24 |
|  pmwhite joined the room. | 19:32:52 |
 richvdh | in my head at least, it's the endpoint version | 19:41:16 |
| richvdh | which is not tightly coupled to the spec version | 19:41:40 |
| richvdh | see send_join for a good example of this | 19:41:50 |
| richvdh | and the CS API is a mess because we tried to tie the endpoint version to the spec version | 19:42:28 |
| richvdh | which basically doesn't work | 19:43:03 |
| tulir | it might work if there were any new spec versions :D | 19:44:16 |
| richvdh | well I think the problem is that we're scared to do new spec versions because doing so requires bumping all the api endpoints | 19:46:47 |
| richvdh | hence in practice we get stuck on r0 forever | 19:46:59 |
 Matthew | while i wasn't a fan of rX at the time, in that i wasn't sure it fixed a big enough problem for the ensuing confusion, i think consistency would be the better part of valour | 23:16:49 |
| Matthew | and i don't understand the "we're scared to do new spec versions" thing, given we release new minor versions fairly regularly? | 23:17:17 |
| Matthew | and the only reason we haven't released a new major version is because we haven't done a breaking change to necessitate it yet (for CS API)? | 23:17:31 |
| Matthew | it certainly feels worst of both worlds to have a weird mix of vX and rX. | 23:18:00 |
| Matthew | but the whole "i have no idea whether i should use the v1 or v2 version of this endpoint, and what other endpoints it is meant to play nice with, or what version of the spec it even relates to" was a genuine problem that rX tries to solve. | 23:18:47 |
| 10 Jan 2020 |
| richvdh | Again, I think we are hampered from making breaking changes by the fact that we would have to change all the endpoints, meaning that even clients which don't use the changed endpoint need to care about it (or we end up having to maintain forks of the spec for each major version) | 06:48:56 |
| richvdh | In practice, we regularly seem to sneak breaking changes in by bending the rules | 06:49:35 |
| richvdh | The solution to the lack of consistency is for r1 of the CS API to go back to being vN style, which should be no harder than making everything r1 | 06:51:47 |
|  Florian Jacob invited  carbeer. | 12:31:19 |
| carbeer joined the room. | 12:31:29 |
| Florian Jacob | richvdh: this room seems to be not listed in the public matrix.org room directory, is this on purpose? 😁 | 12:35:00 |
|  othervdh joined the room. | 12:39:33 |
| richvdh | no | 12:39:56 |
| richvdhchanged room power levels. | 12:40:09 |
| richvdh | fixed | 12:41:10 |
| 11 Jan 2020 |
 Sorunome | what's the MSC so that ASs can receive ephemeral events? | 08:43:17 |
| Sorunome | ah, found it https://github.com/matrix-org/matrix-doc/pull/1888 | 09:00:25 |
 Cadair | They really would be nice | 11:31:00 |
