From d079d7d2d3fa53549f66fcd2c57e5c767cda3232 Mon Sep 17 00:00:00 2001 From: Travis Ralston Date: Thu, 12 Nov 2020 17:51:22 -0700 Subject: [PATCH] Answer question about confusing deprecation with not --- proposals/2844-global-versioning.md | 7 +++++++ 1 file changed, 7 insertions(+) diff --git a/proposals/2844-global-versioning.md b/proposals/2844-global-versioning.md index 73a37afe..224430c4 100644 --- a/proposals/2844-global-versioning.md +++ b/proposals/2844-global-versioning.md @@ -226,6 +226,13 @@ in favour of its proposed `/v4/sync`. Because endpoints are versioned on a per-e will still work with a server that supports `/v3/profile` (for example) - the version number doesn't mean an implementation can only use v4 endpoints. +This sort of approach could be potentially confusing and non-standard as it would mean for an amount of +time in the specification there would be two versions of an endpoint: one deprecated and one not. Most +specifications and protocols do not use this sort of approach and instead opt to replace the whole API +or outright remove the endpoint, however the Matrix specification tends to have a longer-lived cycle +associated with it and thus means we should support a larger than average backwards compatibility +period. + ### Supported versions schedule Currently implementations are left to fend for themselves on deciding which versions of their APIs to