> No, the other clients apart from UWPX and Kaidan (which for obvious reasons very few people use)
A funny thing to say for the 2nd and 3rd most downloaded XMPP-specific clients (from the MS Store and Flathub respectively). Certainly this does not include distro data, but Kaidan is also #1 result on Google when I search "KDE XMPP".
> which is why you'll see the transition to newer versions happen across all clients at roughly the same time.
That's precisely what I'm not seeing. Whenever I try to update my Jabber ecosystem, there's always some incompatibility, and OMEMO has (in recent days) been always at the center of it. Example a couple years ago: Conversations deciding to remove libotr quite early in the OMEMO story, and later other clients chasing suite.
Now I try to update things again and see there's yet another breaking protocol change. It doesn't help that you point that the new protocol is not ready yet but it is already published (as draft) as a XEP and implemented by multiple popular clients.
I'm sure they had "good" security reasons to move forward, even if most users couldn't care less about it (same as what was argued when OTR was dropped).
Then ask the Kaidan developers why they chose to be incompatible - it was a deliberate choice of theirs, they knew what they were doing and what the result would be. It's a surprising decision and not one I, nor (demonstrably) other client developers, would have made.
In most software projects the developers have ultimate freedom on what to implement and how. But nobody is an island in a federated open ecosystem, and there are more responsibilities. In this case the Kaidan developers chose to ignore interoperability and that resulted in a poor experience for Kaidan users. I don't use KDE, so I'm sorry if there are no better options for you.
I don't know what point you're trying to make here. Obviously developers will choose to break compatibility every other day for very flimsy reasons -- I have a million examples, including "Why did Conversations decide to remove OTR support ?" Or even "why are you forking software at all in Snikket?".
My problem here is that XMPP encourages this by adopting a _breaking change_ to a protocol. To my knowledge this is not a client deciding to go out of its way to break compatibility, it's a client deciding to implement the current version of OMEMO and as a consequence ending up incommunicado. If you look at the most recent version of popular XEPs you'll end up with a client that can talk to nobody. This is not a good example of stewardship and doesn't look good look as a candidate for replacing email, a protocol that must last for at least half a century. Core XMPP did look good candidate, but the chase for the shiny has corrupted this protocol as has countless others. Same reason we're down to basically only two workable Jabber server implementations.
Arguments like "oh don't worry, we'll smooth things over by updating all clients in tandem" just don't make me see things better, because I know by experience that it never happens in practice.
A funny thing to say for the 2nd and 3rd most downloaded XMPP-specific clients (from the MS Store and Flathub respectively). Certainly this does not include distro data, but Kaidan is also #1 result on Google when I search "KDE XMPP".
> which is why you'll see the transition to newer versions happen across all clients at roughly the same time.
That's precisely what I'm not seeing. Whenever I try to update my Jabber ecosystem, there's always some incompatibility, and OMEMO has (in recent days) been always at the center of it. Example a couple years ago: Conversations deciding to remove libotr quite early in the OMEMO story, and later other clients chasing suite.
Now I try to update things again and see there's yet another breaking protocol change. It doesn't help that you point that the new protocol is not ready yet but it is already published (as draft) as a XEP and implemented by multiple popular clients.
I'm sure they had "good" security reasons to move forward, even if most users couldn't care less about it (same as what was argued when OTR was dropped).