MSC2844: Global version number for the whole spec #2844

turt2live · 2020-10-30T19:59:04Z

Rendered

proposals/2844-global-versioning.md

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.

proposals/2844-global-versioning.md

Co-authored-by: Andrew Morgan <1342360+anoadragon453@users.noreply.github.com>

turt2live · 2020-11-22T08:23:54Z

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 · 2020-11-22T08:23:56Z

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

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

proposals/2844-global-versioning.md

+   because there's no relevant specification document to link to. Even if there was, it would appear
+   as though we were encouraging the idea of forking a specification as a specification ourselves,
+   which may be confusing if not sending the wrong message entirely. Though the system proposed here


richvdh · 2021-08-03T17:47:28Z

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?

As per [MSC2844](#2844)

turt2live · 2021-10-03T22:43:17Z

Spec PRs:

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

* Update versioning specification for Matrix As per [MSC2844](#2844) * Mention vX versioning in /versions * Changelog

turt2live · 2021-10-12T17:07:49Z

Merged 🎉

deepbluev7 · 2022-02-22T17:51:58Z

proposals/2844-global-versioning.md

+The author does not recommend that this MSC be implemented prior to it landing due to the complexity
+involved as well as the behavioural changes not being possible to implement. However, if an implementation


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/

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.

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.

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.

What if we versioned the whole spec?

5f8b716

turt2live added kind:feature MSC for not-core and not-maintenance stuff proposal A matrix spec change proposal labels Oct 30, 2020

turt2live commented Oct 30, 2020

View reviewed changes