On Thu, 5 Jan 2023 at 10:19, Florian Schmaus <[email protected]> wrote:
> > On 05/01/2023 10.51, Dave Cridland wrote: > > * The argument that this doesn't need a namespace bump is wrong because > > "experimental" has no effect here. The entire point of those 'versioned' > > namespaces was to ensure that we could freely implement Experimental > > XEPs without worrying about causing compatibility nightmares. The > > argument that there's no implementation is counter-productive - if > > there's nobody implementing, then by definition it doesn't matter if you > > bump the namespace. > > +1 > > I see a recent trend in the community that it is acceptable to introduce > backwards incompatible changes in 'experimental' XEPs. I think we are > moving along a dangerous path if this trend continues. > > For a long time, it tended to be the opposite problem - people would add an optional attribute or child element, and then bump the namespace. That's irritating (and harms interoperability in a safe manner), but not as bad as introducing incompatible changes and *not* bumping the namespace. > However, I believe that this trend is part a symptom of a larger > problem. Namely that we e are missing a workflow where people can work > together on a standards document, while implementing what is described > in that document and still be able to react agile regarding protocol > changes. The latter means, amongst other things, being able to introduce > backwards incompatible changes without a namespace bump. > > I think we have that, modulo that if we introduce an incompatible change, we bump the namespace. And in many cases, you can handle both namespaces easily with one or two conditionals, so if you're closely tracking a XEP in your implementation, it's usually OK. The advantage of our model is that if people are not working closely together, it's still safe. > I become more and more convinced that we may be better with an IETF I-D > / RFC style standardization process. Where an I-D is a mutable, living > document on the road to become an immutable RFC. Well... An Experimental XEP maps to an I-D, except we've made ours safe to implement in the wild (fairly) safely. RFCs map to DraftStable/Final XEPs. These still might change, but this really ought to be pretty rare, especially with Final. The fact they're not immutable is, I agree, not ideal - but the static nature of RFCs brings its own set of problems and I'm not really sure which is the better option. I think the thing I'm missing is that I sometimes want to be able to find the latest XEP version covering a particular namespace, but that requires tooling changes etc and I don't care enough to fix it myself, so... Dave.
_______________________________________________ Standards mailing list Info: https://mail.jabber.org/mailman/listinfo/standards Unsubscribe: [email protected] _______________________________________________
