[Standards] (MIX) - When to increment Namespace

Steve Kille steve.kille at isode.com
Wed Jun 14 07:12:06 UTC 2017


> > I have not pushed as a PR because of namespace numbering.      It seems
> > likely that if a change is pushed every time we make a protocol tweak,
> > there is going to be a serious problem of namespace number proliferation.
> >
> > I think the options are:
> >
> > 1.  Keep changes on a working branch and defer pushing.    This gives less
> > visibility of work in progress.
> >
> > 2.  Push and increment namespace.   Problem noted above.
> >
> > 3.  Push the PR and leave version number on mix:0.    I think this may be
> > the pragmatic solution,  provided it does not cause a problem for
> > those coding.
> This is a general question. In software library development, one would have
> a major update (here: things which require a namespace bump) branch and a
> minor update (here: things which do not require a namespace bump) branch,
> with the minor changes continuously flowing in the currently supported
> release.
> However, the XEP process does not make it easy to have these two branches
> exist in parallel in a manner which allows easy viewing and discussing.
[Steve Kille] 

I think the software analogy is a good one.   It feels sensible to increment namespace at "key delivery points" rather than for each minor protocol twiddle.

An implementation supporting mix:2 might have some fallback if it gets mix:1 PDUs.       I find it harder to see something supporting mix:42 having fallback for a mix:37 PDU.

MIX 0.9.3 has made a protocol change relative to MIX 0.9.2.     The practical  question is - when do we change from mix:0 to mix:1?

> In this particular case, I’d suggest seeking consensus`from those who work
> on implementations. Or maybe someone deeper in the XSF has knowledge
> about any requirements in the process regarding this, I haven’t looked it up.
[Steve Kille] 

Some expert guidance would be appreciated

> kind regards & thanks,
> Jonas
[Steve Kille] 

Thanks for the quick and helpful response


More information about the Standards mailing list