On Mon, 2024-06-03 at 18:29 +0300, MSavoritias wrote: > Agreed. We don't need yet more XEP numbers to shift through. We > already > have way too many of them. > Instead we should start using the namespaces more. And also we > shouldnt > be afraid to update Stable XEPs if there are substaincial changes. I > mean we have feature discovery and namespaces for that reason :)
Totally viable option. I would even go further with this (knowing it doesn't work exactly like this for some specifications): - An Experimental XEP is identified only by its namespace. Namespaces are cheap so we can give them out to everyone without any evaluation whatsoever. - When a XEP is turned into Stable, it gets a number. The primary identifier remains to be the namespace. - When we bump a namespace of a XEP it's effectively a new XEP (because the identifier is a new one) and thus goes to Experimental. It also looses it's number (or the number continues to refer to the previous namespace) but we remember what number it was derived from. - When a XEP goes to Stable that was derived from a XEP that had a number, we reassign the number to the newer XEP, so the XEP number is always referring to the latest stable version of that XEP. Thereby we allow for breaking changes through namespace bumps, won't shift through numbers and a XEP when identified by its namespace would never see incompatible changes after being moved to Stable, but when identified by its number it would always refer to the latest version. Problem is: People already have an understanding of the XEP numbering system, so we can't easily change that. If two implementations implement a Stable version of a XEP number, we currently expect those two to be able to talk with each other. A namespace bump would prevent that, so it would be good to at least keep the specification for the old namespace around as Deprecated. I really dislike how we currently in OMEMO have to refer to a specific Experimental version when talking about what the production software implements. Marvin _______________________________________________ Standards mailing list -- [email protected] To unsubscribe send an email to [email protected]
