30 Nov
2023
30 Nov
'23
7:46 p.m.
Has this been discussed much before? SCE clearly calls out OX as
inspiration, but especially since both are still experimental would it not
make sense to "reverse the arrow" and have OX be a profile of SCE?
1 Dec
1 Dec
1:52 a.m.
On 01/12/2023 03.46, Stephen Paul Weber wrote:
Has this been discussed much before? SCE clearly
calls out OX as
inspiration, but especially since both are still experimental would it
not make sense to "reverse the arrow" and have OX be a profile of SCE?
Yes this is probably sensible.
However, OX-based-on-SCE is an excellent example of a breaking change
that we should introduce together with other backward incompatible
changes of the OX protocol. Because bumping OX's namespace just for this
alone would not be justified, as the price one has to pay for a
namespace bump is pretty high.
I assume the effort that comes with a namespace bump is why some people
believe we should introduce breaking changes without a namespace bump
for experimental XEPs [1]. Nevertheless, the cost of the resulting
interoperability chaos is far higher than proper namespace bumps.
The fact that the OX XEP is experimental does not mean we can introduce
breaking changes without namespace bumps. What matters is how long the
specification exists, if there are existing implementations, and, most
importantly, if the specification communicates that it can change in an
incompatible way without a namespace bump.
Two adjustments can vastly improve our standards process.
1. Introduce a pre-experimental phase for XEPs similar to IETF's I-Ds,
where the XEPs do not have a number, do not require council approval,
and changes do not require a namespace bump. Of course, the XEP's header
must clearly and visibly state these conditions.
2. Properly gather breaking changes for XEPs. We failed to do so, for
example, with MAM, where we had a namespace bump for a minor change,
only to introduce another bump afterward (IIRC, it was mam:2 to mam:3).
This could be achieved by having a staging area for new namespace
versions of XEPs, where the new namespace is xepshortname:3-SNAPSHOT
(or, -NEXT, or whatever) [2].
- Flow
1: I know that you did not explicitly ask for this. But pointing out
that the XEP is experimental could be interpreted as hinting towards this.
2: Yes, this appears similar to the :tmp namespaces we once had. And we
stopped using them for a good reason. However, if my memory serves me
right, they where differently used.
5 Dec
5 Dec
8:02 a.m.
Somebody signing messages as Florian Schmaus wrote:
On 01/12/2023 03.46, Stephen Paul Weber wrote:
Glad you agree.
Has this been discussed much before? SCE clearly
calls out OX as
inspiration, but especially since both are still experimental would
it not make sense to "reverse the arrow" and have OX be a profile of
SCE?
Yes this is probably sensible. I assume the effort that comes with a namespace bump is
why some people
believe we should introduce breaking changes without a namespace bump for
experimental XEPs [1]. Nevertheless, the cost of the resulting
interoperability chaos is far higher than proper namespace bumps.
Certainly there are many changes that are not breaking and don't need a
namespace bump, but I doubt this is one of them. Are there other changes
you expect to be worth "bundling" with the next namespace bump?
I do think there is some cost to *not* doing the change sooner however, and
that is the risk that even more implementations will implement the
currently-published version and thus even more will have to do rework after
the changes. Perhaps if we at least put it in a draft PR then people can
see how it will be when implementing?
1. Introduce a pre-experimental phase for XEPs similar
to IETF's I-Ds,
where the XEPs do not have a number, do not require council approval,
and changes do not require a namespace bump. Of course, the XEP's header
must clearly and visibly state these conditions.
I honestly don't think this would be a change. Sure, we have PR and inbox
phase, but as you say in the end sometimes we care about pain to
implementations more than we care about what the process specifies. Already
experimental specifies to not use these XEP in production software and to
expect changes at any time, yet in practise people do deploy experimental
XEP implementations widely and so we are incentivized to do things like
namespace bumps and careful updates even there. I think if we move things
down from experimental to PR or draft PR status we will find people
implementing draft PRs in production software (I've certainly been guilty of
that at least once) and end up in the same situation.
167
days inactive
171
days old
2 comments
2 participants
participants (2)
-
Florian Schmaus -
Stephen Paul Weber