State a policy regarding deprecation of old spec/API versions on matrix.org servers

[alphapapa]

Hi,

It would be helpful for client authors if the Matrix organization (i.e. the one that runs the official matrix.org servers) were to state a policy about whether and when old spec/API versions will be deprecated.

I'm an author of a small client that I worked on in spare time, and it hasn't been practical for me to keep up with the new spec versions in the last couple of years. Sometimes I think about whether it would be worth it to try to write support for newer versions of the spec. My concern is how long my work would remain usable. If I knew that it would continue working on the official Matrix server, I'd be more motivated to work on it. But since Matrix doesn't seem to have a stated policy about this, I feel like I could wake up one day to an announcement that r0.X.Y will be dropped by matrix.org servers in a few months, and that my client would then stop working. Were that the case, I'm not sure whether my work would be worth the time.

To be clear, I don't mean this as a complaint or a demand. I don't necessarily expect old spec versions to be supported indefinitely, even though it would be good to support them as long as possible to ensure that clients continue working. And I don't expect that exceptions to a policy would never arise.

What I'm asking for is some kind of a stated policy about intentions, something like, "To the extent possible, we intend to support each version of the client-server spec for X years on the official matrix.org servers." That would be very helpful for authors of client software who want to plan long-term.

(I searched the official spec for "deprecat" and found no results. I also searched the list of open and closed issues for related terms and didn't find an issue about this, so it seems reasonable to open a new one.)

Thanks for your work.

[turt2live]

The matrix.org homeserver doesn't really have a role in determining this sort of thing. The intention has always been that clients can support whatever specification versions they want, though agreed this isn't advertised very well. Typically clients will support the latest version at the time of writing, then only support specification versions which are moderately recent.

[alphapapa]

Okay, to rephrase my request into a specific question, then: How long will, say, the r0.3.0 client-server API be supported by Synapse and Dendrite? And how long will that API version be supported by the official matrix.org homeserver?

Is the answer intended to be "forever"? Or "until we find a problem that requires a backward-incompatible change in the spec, which we can't predict, and hopefully won't ever happen"? Or...?

I guess what I'm asking for is some kind of public commitment--to the extent feasible--to support certain versions of the API for a certain period of time, or "indefinitely, unless extreme circumstances were to arise," etc. Or, if not a firm commitment, even a statement of intent with specific regard to supporting the API versions.

It would give me more confidence as a client developer, and I think it would be beneficial to the Matrix ecosystem in the long term, as well.

[turt2live]

That would be a question for each of those 3 individual projects - the spec doesn't have an answer for that. The older a version is, the less likely something is to support it.

[alphapapa]

Okay, well, I feel kind of like we've gone in a circle and are now back at my initial question: How long will the official Matrix homeserver support r0.3.0? Or what is the policy about supporting spec versions in general?

If this is not the appropriate place to ask this question, please redirect me. :) And in that case, this issue might be repurposed to suggest mentioning this matter in the spec, i.e. maybe the spec should suggest a policy that implementations and servers/networks should follow. Doing so might help prevent fragmentation in the future.

Thanks for your help.

[turt2live]

How long will the official Matrix homeserver support r0.3.0?

As mentioned, this cannot be answered by the spec. This repository is for the spec.

what is the policy about supporting spec versions in general?

Also as mentioned, this needs clarifying in the spec. There is currently an implicit policy, but no formal writing for it. This issue serves as the placeholder for us writing the policy down.

[alphapapa]

As mentioned, this cannot be answered by the spec. This repository is for the spec.

Very well. Would you please direct me to an appropriate place to ask about the intention for the official homeserver?

Also as mentioned, this needs clarifying in the spec. There is currently an implicit policy, but no formal writing for it. This issue serves as the placeholder for us writing the policy down.

Thanks.

[turt2live]

support@matrix.org is probably your best bet, though a lot of patience will be required as replies are not guaranteed to be quick.

[alphapapa]

Hm, I was hoping for something more like an issue tracker where it could be posted and discussed publicly. Maybe I'll wait and see how this issue progresses. Thanks.

[turt2live]

moved to matrix.org repo as the site will be the best place to track this