MSC2844: Global version number for the whole spec

[turt2live]

Rendered

[anoadragon453]

Overall I think this is a great change, which will not only encourage more frequent releases, but also simplify discussion of the Matrix spec in general. I thought your points were well thought out and I agree on the whole.

I have a few questions, suggestions and clarifications below, but otherwise this seems sane.

[turt2live]

All the initial feedback has been addressed, and this seems to be getting supportive comments out of band. Per the MSC, this has a rudimentary implementation at https://adoring-einstein-5ea514.netlify.app/ (see "releases" dropdown in the top right) to prove that the website component works. I don't think it's practical to have an implementation proof of the remainder of the MSC - it'll have to be explored and analyzed in practice if this MSC is to be accepted.

As such,

@mscbot fcp merge

[mscbot]

Team member @turt2live has proposed to merge this. The next step is review by the rest of the tagged people:

• @dbkr
• @uhoreg
• @turt2live
• @ara4n
• @anoadragon453
• @richvdh
• @erikjohnston
• @KitsuneRal

Once at least 75% of reviewers approve (and there are no outstanding concerns), this will enter its final comment period. If you spot a major issue that hasn't been raised at any point in this process, please speak up!

See this document for information about what commands tagged team members can give me.

[erkinalp]

Do not forget the obligatory XKCD reference about standards

[richvdh]

Next steps on this, while I remember:

• An update to https://spec.matrix.org/unstable/#specification-versions to document the way matrix spec versions work in the brave new world.
• An update to https://spec.matrix.org/unstable/client-server-api/#get_matrixclientversions to include v1.1, as documented at https://github.com/matrix-org/matrix-doc/blob/master/proposals/2844-global-versioning.md#endpoint-versioning
• Replace %CLIENT_MAJOR_VERSION% everywhere with v3. Note that this will break a load of anchors, so we'll need to find links to those.
• Do something about https://spec.matrix.org/unstable/#matrix-versions, which looks redundant?

[turt2live]

Spec PRs:

• Describe new global specification versioning #3420
• Update client-server API endpoints to move from r0 to v3 (plus whitespace fixes) #3421

I don't believe there's anything else remaining on this MSC to cover.

[turt2live]

Merged 🎉

[deepbluev7]

It might make sense to require an implementation even for changes like this in the future, because such large changes can always break (maybe badly written) clients in new and exciting ways: Nheko-Reborn/nheko#957

For the same reason web clients, like Firefox and Chrome, take adding even a single digit to their version number very seriously: https://hacks.mozilla.org/2022/02/version-100-in-chrome-and-firefox/

[turt2live]

fwiw, the belief was that through several blog posts, notifying clients specifically, and general spec activity folks would be aware of this happening to make the required changes.

Even with an implementation, I don't believe it would have caught your specific failure mode.

[deepbluev7]

Well, I did not know that someone added validation code for that 5 years ago. I didn't even know about Matrix at the time. Having a server that exports the new version and testing clients against it sounds not that unreasonable and because of how big and varied the WWW has become, browsers actually go through the effort to do that. Since Matrix is growing too, if there is ever a version format change again (which is very unlikely), it probably makes sense to go with a similar approach and actually test if anything expects the format not to change. Testing always trumps just reading about it and guessing if it will break anything. Anyway, this is not a complaint, just something I thought I might notify people about and which might make sense to keep in mind for the future.

[turt2live]

The spec doesn't allow for experimental versions in that field, and even if it did I don't think people would be aware of a server which had the support if they weren't aware of other aspects.

Implementation and testing is always better, yes, but I don't believe it'd fix the particular problem case raised here. It's worth noting for the future though.