[Standards] (MIX) - When to increment Namespace
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:
>>>> 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
>>>> I think the options are:
>>>> 1. Keep changes on a working branch and defer pushing. This gives
>>>> 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
>>>> the pragmatic solution, provided it does not cause a problem for
>>>> those coding.
>>> This is a general question. In software library development, one would
>>> 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
>>> 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
> 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
> 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