[QUESTION] How are you relating to the clients code like py-redis?

[netanelrevah]

Are you going to "fork" them too?

[sixwaaaay]

Most of the Redis client implementations are still OSI open-source projects.

[madolson]

We're still investigating what makes the most sense. For now there is not plan to proactively fork the other clients. We are working on getting clients to explicitly indicate what their compatibility is though so it's clear what clients you can use.

[stalkerg]

Same for Redict, but people want to fork it just to keep name. Honestly it's not a good situation if we will have almost identical client libraries but by different names. Can Redict and Valkey make any agreement about a such libs? Also, as I understand it still controlled by Redis Lab and they can provide protection to avoid use it on Valkey and Redict.

[madolson]

Can Redict and Valkey make any agreement about a such libs? Also, as I understand it still controlled by Redis Lab and they can provide protection to avoid use it on Valkey and Redict.

Unless I'm mistaken, the plan for redict is to basically stay API compatible with 7.2 forever right? In which case, whatever clients we consolidate around should also support what you want. Maybe the only thing we should make sure is we consolidate on a generic name (Maybe we pretend RESP stands for re-usable serialization protocol :) )

[stalkerg]

Unless I'm mistaken, the plan for redict is to basically stay API compatible with 7.2 forever right?

yes, sure, at least as long as possible, I believe Valkey have the same position.

Maybe the only thing we should make sure is we consolidate on a generic name (Maybe we pretend RESP stands for re-usable serialization protocol :) )

I suppose it's a good idea.