Re: [Standards] XEP Versioning

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

Re: [Standards] XEP Versioning

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

Re: [Standards] XEP Versioning

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

Re: [Standards] XEP Versioning

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

[Standards] XEP Versioning

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