Publish a guide for how to handle room version-affecting MSCs #1004
Description
From a DM I sent to someone:
With a traditional MSC, you'd add an unstable prefix/flag that survives for however long you need it to, however with room versions they are longer-lasting than most would typically expect. First the MSC needs to describe the functionality and be implemented, but it will not have an assigned room version yet, so it uses the unstable prefix to describe the room version number to operate within (where digits are reserved by the specification and regular namespacing rules otherwise apply). That room version is expected to exist for a while, up until the MSC gets approved and assigned a room version number by a different MSC.
For room version 10, that curating MSC is matrix-org/matrix-spec-proposals#3604 which will take a combination of MSCs to assign them to v10 and fall into its own testing procedure. It also gets an unstable prefix as a room version so we can make sure all the functionality operates happily together. After that MSC is accepted, it becomes spec and the two unstable room versions can be removed in favour of the stable one.
Clients will also complain about stability of unstable room versions because they're, well, unstable. During development it's best to just ignore the warnings. It's also important to not put any data you care about in these unstable rooms, as the server can and will remove support for that room version and it'll cease functioning.
The SCT almost always does the curation process (assigning things to v10, for example) because it's super annoying for a contributor or even regular core team member. The SCT holds the context on what is "safe" for a given room version, so does the curation.