MSC4209: Updating endpoints in-place #4209
Conversation
turt2live
added
proposal
There was a problem hiding this comment.
Implementation requirements:
- None? This is a policy clarification.
turt2live
removed
the
needs-implementation
| the version change. Servers which advertise support for old specification versions are still required | ||
| to implement both old and new endpoint. | ||
|
|
||
| This proposal does not apply to situations where the endpoint changes namespace, path structure, etc. |
There was a problem hiding this comment.
What's the reasoning behind limiting in-place updates without deprecation to version changes in the path? Could these not involve drastic behavioral changes of the endpoint's behavior similar to the excluded situations listed here?
|
|
||
| ## Potential issues | ||
|
|
||
| No major issues are foreseen. |
There was a problem hiding this comment.
This proposal will result in the spec listing a single situation in which deprecation can be skipped. This in turn implies that deprecation is mandatory for all other breaking changes. Is this intended?
|
|
||
| ## Alternatives | ||
|
|
||
| There are no significant alternatives. |
There was a problem hiding this comment.
Probably not significant but instead of listing situations that are exempt from deprecation, we could also list situations that require deprecation.
|
|
||
| There may be situations where explicitly listing the old endpoint as deprecated in the specification | ||
| is preferred. This is supported by this policy clarification, and left to the discretion of the Spec | ||
| Core Team (SCT) during PR review. |
There was a problem hiding this comment.
Since removal without deprecation is the intended default case, maybe it'd be better to formulate this as the old endpoint being automatically removed and the SCT having discretion to mandate deprecation? The current wording "automatically deprecated and can be removed" left me slightly confused in the beginning because if it's removed, it's no longer deprecated.
Rendered
In line with matrix-org/matrix-spec#1700, the following disclosure applies:
I am Director of Standards Development at The Matrix.org Foundation C.I.C., Matrix Spec Core Team (SCT) member, employed by Element, and operate the t2bot.io service. This proposal is written and published as Director of Standards Development to assist in furthering the spec.