[Standards] (MIX) - When to increment Namespace

Jonas Wielicki jonas at wielicki.name
Wed Jun 14 07:31:39 UTC 2017


On Mittwoch, 14. Juni 2017 08:12:06 CEST Steve Kille wrote:
> Jonas,
> 
> > > 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.

To clarify: what I meant is that a major release is required when 
compatibility is broken (here: something which implements mix:0 would behave 
incorrectly given everything specified (including the ignore rules in RFC 
6120) when it interacts with an implementation which includes the proposed 
changes).

What I meant to suggest was to buffer the "breaking" changes in a branch and 
put them together to a major (namespace incrementing) release, while merging 
the non-breaking changes into the currently-published XEP.

Again, this needs input from both people more familiar with the XEP process 
than me and also implementors.


kind regards,
Jonas
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 833 bytes
Desc: This is a digitally signed message part.
URL: <http://mail.jabber.org/pipermail/standards/attachments/20170614/f8bdf9ea/attachment.sig>


More information about the Standards mailing list