> Breaking the existing deployed network every time a new feature is added is unfortunately not a solution for an open ecosystem.
I didn't say it but yes, the support for old version for some time would need to be a thing. But it should be defined (say "3 years for last minor release of every version") so it can be planned for
> While there are obviously limits to how far backwards compatibility should go, it doesn't make sense to deny users basic messaging just because their app doesn't implement calls for example. That would just cause a different set of frustrations.
As you clearly didn't bother to read before you answered, here is what I mentioned in comment you didn't bother to read before answering
> with maybe optional "XMPP voice comms", "XMPP video comms" pack of features (for those cases where full voice/video chat is not relevant).
I don't argue for single version, but to very small subset of featuresets instead of sea of XEPs
I didn't say it but yes, the support for old version for some time would need to be a thing. But it should be defined (say "3 years for last minor release of every version") so it can be planned for
> While there are obviously limits to how far backwards compatibility should go, it doesn't make sense to deny users basic messaging just because their app doesn't implement calls for example. That would just cause a different set of frustrations.
As you clearly didn't bother to read before you answered, here is what I mentioned in comment you didn't bother to read before answering
> with maybe optional "XMPP voice comms", "XMPP video comms" pack of features (for those cases where full voice/video chat is not relevant).
I don't argue for single version, but to very small subset of featuresets instead of sea of XEPs