Skip to content

MSC4209: Updating endpoints in-place#4209

Open
turt2live wants to merge 1 commit into
mainfrom
travis/msc/deprecated-endpoints
Open

MSC4209: Updating endpoints in-place#4209
turt2live wants to merge 1 commit into
mainfrom
travis/msc/deprecated-endpoints

Conversation

@turt2live
Copy link
Copy Markdown
Member

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.

@turt2live turt2live added proposal A matrix spec change proposal. Process state. T-Meta Something that is not a spec change/request and is not related to the build tools kind:maintenance MSC which clarifies/updates existing spec needs-implementation This MSC does not have a qualifying implementation for the SCT to review. The MSC cannot enter FCP. labels Oct 2, 2024
Copy link
Copy Markdown
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Implementation requirements:

  • None? This is a policy clarification.

@turt2live turt2live removed the needs-implementation This MSC does not have a qualifying implementation for the SCT to review. The MSC cannot enter FCP. label Oct 2, 2024
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.
Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

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.
Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

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.
Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

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.
Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

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.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

hacktoberfest-accepted kind:maintenance MSC which clarifies/updates existing spec proposal A matrix spec change proposal. Process state. T-Meta Something that is not a spec change/request and is not related to the build tools

Projects

None yet

Development

Successfully merging this pull request may close these issues.

2 participants