[Standards] long specs

Matthew Wild mwild1 at gmail.com
Thu Feb 16 00:18:07 UTC 2012


On 15 February 2012 22:47, Ben Langfeld <ben at langfeld.co.uk> wrote:
> I like the idea of splitting out non-essential elements of XEP-0045
> into separate documents. I can then say my code fully implements
> MUC-basic, but not MUC-admin, etc.
>
> As for the versioning issue. Why not have XEPs follow semver?

They sort of do (and sort of don't). See for example:
http://xmpp.org/extensions/xep-0045.html#appendix-revs

However XEP-0001 mandates that Draft == 1.0, and Final == 2.0,
regardless of the actual changes made between the status change. I
don't have strong feeling about "fixing" this, since namespaces are
our mechanism for versioning different incompatible versions of the
same protocol.

XEP-0001 doesn't mention the distinction between which changes should
increment the second component and which the third component of the
version. Again, I'm not sure it's something we need to change.

Finally, we already use rc numbers for candidate changes to an
existing XEP: http://xmpp.org/extensions/diff/api/xep/0045/diff/1.25/vs/1.25rc9
. Typically these "interim" versions are quite short-lived, and I'm
not sure anyone would really implement them from an interim document.

What I believe Dave is referring to is essentially keeping the interim
versions around for longer, and making them more public - expecting
people to implement them before they become the next "official"
version of the XEP.

Personally I find that a bit over the top... one version of a XEP
works well enough in my opinion. If we really want to make such
drastic changes to a XEP that we're concerned about replacing an
existing stable version, we really should make the changes a new XEP.
We're not going to run out of numbers just yet :)

Regards,
Matthew



More information about the Standards mailing list