4 Jun
2024
4 Jun
'24
11:10 a.m.
I'm catching up on this thread and I'm replying to two of your mails at
the same time.
On Mon, 03 Jun 2024 12:37:21 +0200, Marvin W wrote:
I tried to circumvent this by writing XEP-0447 [..]
yet there already have
been implementations from the community in released software.
This underlines my point that Experimental is considered "ready for use in
production software" by some.
No, this only says that this is a much needed feature, whether or not the
protocol is considered "ready for use in production software" (whatever that
means[0]) is irrelevant IMO.
As explained, we have de-facto reached the state where
something that's
considered useful to developers is in Experimental for more than a few
months, we will see it in production and therefor will have to consider
interoperability and compatibility with this specific Experimental version
for at least some time. And that is where the feeling for the need of a
higher bar to Experimental comes from. So to reduce the bar for
Experimental, we have to move to Stable faster or the ecosystem will move
faster than we manage the XEPs.
Experimental isn't the issue. The thing is that people want features /
improvements and will implement them, and that's great. There's no preventing
it. By doing so they should also ready to also do the work to update their
software whenever the spec gets updated.
because Experimental shouldn't have had
implementations.
How does one even experiment without implementation?
3. We should more actively discourage release of
functionality based on
ProtoXEP and Experimental XEPs in production (except hidden behind feature
flags or options clearly marked as experimental).
And that's how you end up with Pidgin not having MAM or the like for years.
Because they indeed refuse to implement Experimental specs.
Life happens, and people working on specs also get hit by buses / have
other things to take care of. The burden can't be put on just one person
alone to do the work. It happens but it's rare that council does
something about it.
In other words. You can discourage all you want, that won't stop anybody from
implementing what they need. And I'd rather have people take a half-baked spec
in Experimental and try to improve on it and report back. They may release it
however they want.
On Mon, 03 Jun 2024 14:58:23 +0200, Marvin W wrote:
On Mon, 2024-06-03 at 14:10 +0200, Goffi wrote:
> The "experimental" state is clear: it may change and break.
That seems to not be clear to anyone, to be honest,
especially not end-
users and also not in how we market our products.
Yes it is clear. It's you that don't want to accept that people may choose to
implement a protocol that will likely break.
Your following example with 0384 is only good in that it would have made
it much more easy to find if there was another XEP number assigned for >
0.3.0, as flow and goffi have said (or will say?) in this thread.
[0]: https://bouah.net/2022/09/versioning/