[Standards] (MIX) - When to increment Namespace

Kevin Smith kevin.smith at isode.com
Wed Jun 14 07:38:50 UTC 2017

On 14 Jun 2017, at 08:31, Jonas Wielicki <jonas at wielicki.name> wrote:
> 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.

I think this is what I’m proposing, mostly. Just to not publish the new version until the breaking changes are bunched together - the version-to-be is still available in Steve’s repo, and it’d be straightforward to keep a render of the preversion.


More information about the Standards mailing list