Re: [Standards] XEP Versioning

[Jonas Schäfer]

Hi Melvin,

On Mittwoch, 24. August 2022 19:41:49 CEST Melvin Keskin wrote:
> What is the reason for having a state such as Stable or Final and a
> redundant state (major) version?

I wish I knew. It's how it was always done™.

> In my opinion, it would make more sense to have a separate state and
> semantic versioning as specified by https://semver.org . Or, if for any
> reason the state must be declared by the version, the version
> scheme state.major.minor.patch as Zash said in xmpp:
> x...@muc.xmpp.org?join would make more sense to me. The namespace would
> then change when the major version changes. Developers as well as XEP
> lists could quickly determine if there was a breaking change by
> checking the major version.

I agree.

However, we have a huge corpus of XEPs which have not followed that scheme, 
which is why I think attempting to write down something in XEP-0001 for the 
versioning scheme is not going to work that simple. Even just the "a XEP MUST 
have a version of the form .." thing is not compatible 
with a huge amount of existing revisions. See the attic [1] for examples.

Any ideas how to fix that -- *without* rewriting all XEP history and 
invalidating all existing version references -- highly welcome.

When I first became editor I started to enforce minor and patch level 
distinction at least, but it's a tedious process and I'm sure I didn't always 
catch it. So we cannot really promise semver I'm afraid, neither for old nor 
for recent documents.

kind regards,
Jonas

   [1]: https://xmpp.org/extensions/attic/

signature.asc
Description: This is a digitally signed message part.
___
Standards mailing list
Info: https://mail.jabber.org/mailman/listinfo/standards
Unsubscribe: standards-unsubscr...@xmpp.org
___

Re: [Standards] XEP Versioning

[Philipp Hörist]

Hi,

I just wanted to throw into the discussion that breaking changes is not the
only thing to consider.
Often new features are added to XEPs which are not breaking but someone
still wants to know if a client implements it.

Example XEP: 0045
Version 1.30: Add 333 status code with OPTIONAL feature.

As a server/client developer i can imagine that a quick scan over all
clients/servers who implements > 1.30 can be useful.

This happens in my opinion more often in XEPs than breaking changes which
need a namespace bump.

Regards
Philipp
___
Standards mailing list
Info: https://mail.jabber.org/mailman/listinfo/standards
Unsubscribe: standards-unsubscr...@xmpp.org
___

Re: [Standards] XEP Versioning

[Melvin Keskin]

Hi Dave,

thanks for your explanation!

What is the reason for having a state such as Stable or Final and a
redundant state (major) version?

In my opinion, it would make more sense to have a separate state and
semantic versioning as specified by https://semver.org . Or, if for any
reason the state must be declared by the version, the version
scheme state.major.minor.patch as Zash said in xmpp:
x...@muc.xmpp.org?join would make more sense to me. The namespace would
then change when the major version changes. Developers as well as XEP
lists could quickly determine if there was a breaking change by
checking the major version.


___
Standards mailing list
Info: https://mail.jabber.org/mailman/listinfo/standards
Unsubscribe: standards-unsubscr...@xmpp.org
___

Re: [Standards] XEP Versioning

[Dave Cridland]

Hi,

I like that we're documenting the versioning mechanism we use for XEPs, so
- to be clear - I don't object to this change at all.

I'm not so sure on the rationale given, though:

@horazont  The reason for specifying that
topic was that @wurstsalat3000  wanted
to create a list of XEPs a client, library or server implements and show a
hint if the implemented version is not up-to-date. But such a hint should
not be shown for different patch versions since they are only meant for
editorial changes. The problem was that it was not clear and we could not
find any document that specified it. I will sent a link to this PR to the
corresponding mailing list.


(From GitHub)

So, if the XEP changes but it's purely editorial - that is, an
implementation is very unlikely to require changes - then as this comment
says it's irrelevant to interoperability.

If a major version changes, it is also irrelevant to interoperability,
though, since advancement doesn't change the XEP's content, only its state.

And if the minor version changes, it might have an effect on
interoperability or might not depending on whether the namespace changes.
If the namespace does not change between versions but we break interop,
then we have well and truly fucked up. (And if it was in
Active/Stable/Final, then Council have to buy us all beers or chocolate, as
per XEP-0028).

So should we maybe have that list show the hint based on the namespace, and
not the version number?

I've always assumed the version number to be as Kev says in his comment -
but perhaps more usefully, it's most useful as an opaque label for a
particular version, and semantics are best ignored outside of process
wonkery.

So yes, document away, but don't list XEPs by version - list them by
namespace if we need that level.

Dave.

On Wed, 24 Aug 2022 at 13:57, Melvin Keskin  wrote:

> Hi,
>
> I created a PR for precisely specifying the versioning of XEPs:
> https://github.com/xsf/xeps/pull/1200
>
> Here is the reason:
> https://github.com/xsf/xeps/pull/1200#issuecomment-1225678948
>
> Please let me know what you think.
>
> ___
> Standards mailing list
> Info: https://mail.jabber.org/mailman/listinfo/standards
> Unsubscribe: standards-unsubscr...@xmpp.org
> ___
>
___
Standards mailing list
Info: https://mail.jabber.org/mailman/listinfo/standards
Unsubscribe: standards-unsubscr...@xmpp.org
___

[Standards] XEP Versioning

[Melvin Keskin]

Hi,

I created a PR for precisely specifying the versioning of XEPs:
https://github.com/xsf/xeps/pull/1200

Here is the reason:
https://github.com/xsf/xeps/pull/1200#issuecomment-1225678948

Please let me know what you think.

___
Standards mailing list
Info: https://mail.jabber.org/mailman/listinfo/standards
Unsubscribe: standards-unsubscr...@xmpp.org
___