Add stable unstable feature for jump to date before v1.6 is fully supported on Synapse

[MadLittleMods]

Add stable unstable feature (org.matrix.msc3030.stable) for jump to date before v1.6 is fully supported on a homeserver. Discussion for whether we are okay with moving forward with this -> #15283 (comment)

Related to #15089

Fix element-hq/element-web#24362

Element Web PR to honor org.matrix.msc3030.stable: matrix-org/matrix-react-sdk#10398

Pull Request Checklist

• Pull request is based on the develop branch
• Pull request includes a changelog file. The entry should:
  • Be a short description of your change which makes sense to users. "Fixed a bug that prevented receiving messages from other servers." instead of "Moved X method from EventStore to EventWorkerStore.".
  • Use markdown where necessary, mostly for code blocks.
  • End with either a period (.) or an exclamation mark (!).
  • Start with a capital letter.
  • Feel free to credit yourself, by adding a sentence "Contributed by @github_username." or "Contributed by [Your Name]." to the end of the entry.
• Pull request includes a sign off
• Code style is correct
  (run the linters)

[MadLittleMods]

Add stable unstable version (org.matrix.msc3030.stable) for jump to date before v1.6 is fully supported on a homeserver.

org.matrix.msc3030.stable wasn't included in MSC3030 but it seems like pattern that should have been included like MSC2285 as an example.

Are we okay with moving forward with this? Since this is in unstable_features, it seems like we can make any decision although I wish we included it in the MSC for completeness sake.

There is another open thread on the Element Web PR to honor org.matrix.msc3030.stable but it doesn't have any further points.

[clokep]

I'd rather see us support v1.6 (#15089). I don't think the work is that extensive, although I empathize with it not being directly related to this.

[clokep]

(I believe the stable flags are also considered poor form and we try not to use them? I forget where I got that from though.)

[MadLittleMods]

(I believe the stable flags are also considered poor form and we try not to use them? I forget where I got that from though.)

Seems like a great pattern to me. I wish I had included it on the MSC and seems like it should be followed in other MSC's. Curious of the discussion if you find it.

[clokep]

I can't seem to find the original conversation, but it was something along the lines of:

• It adds 3 phases to to an MSC implementation (unstable, stable-but-unversioned, versioned); which creates:
  • More implementation work (and more potential for bugs).
  • Harder to deprecate -- you need to separately deprecate the unstable version; then the stable-but-unversioned branches.
• This shouldn't really be necessary as spec releases are done fairly often now.

---

Regardless, this isn't in the MSC and this is now in the spec, so I think the way forward is to implement support for the specced version? Otherwise both Synapse and any clients using this will be out of spec.

[turt2live]

fwiw, the unstable prefix section of an MSC is considered non-normative, which means it can change if needed to support the goals of implementation.

I also can't find the relevant discussion on this, but @clokep's summary is correct. I would also suggest just jumping to stable: the remaining effort of Synapse's converstion to v1.6 appears to be relatively trivial and would be faster to do than managing an unstable-but-stable flag.

[MadLittleMods]

There is a related discussion at matrix-org/matrix-js-sdk#2915 (comment) (maybe even a mention of the fabled internal conversation that you're thinking of which you may be able to find given the dates)

For a timeline:

• MSC3030 was merged on 2022-11-06
• MSC3030 was added to Matrix v1.6 in 2023-02-14 (t+3M)
• Synapse still does not advertise support for v1.6 yet (t+4.5M as of posting)

The Gitter stuff got in the way of moving jump to date forward quicker back when that other discussion happened. And now it appears from your inklings that we're probably closer to just having v1.6 in Synapse which works ⏩

But if I was moving faster there, we should have a standard suggested path for these situations. A suggestion of waiting for complete stable isn't satisfactory.

We could have kept the unstable endpoint and feature around longer but there is complexity to support both stable and unstable and we don't have to let breaking unstable and labs features slow us down (more thoughts).

[MadLittleMods]

v1.6 support merged into Synapse via #15089 on 2023-05-12 (t+6M)

I think this illustrates why we can't just wait for things to be stable when you're trying to actively work on something.

[MadLittleMods]

Related thread from @clokep in the #matrix-spec room on how we can standardize these type of things

[clokep]

@MadLittleMods I think we can close this now that #15089 has landed?