The problem/use-case that the feature addresses
As mentioned in #36, changing "master" and "slave" the replies of commands like ROLE and CLUSTER SHARDS are breaking changes. From feedback, we've learned that backward compatibility is more important than inclusive language.
Description of the feature
Opt-in for inclusive language. An idea is to use CLIENT CAPA introduced in #325. Idea:
CLIENT CAPA inclusive-languageCLIENT CAPA woke 🤣CLIENT CAPA primary-replica
When a client has declared this capability, the server can send "primary" and "replica" in replies to ROLE and other commands.
Alternatives you've considered
- Breaking change (not appreciated by users)
- No change at all (some people will complain forever that we still use non-inclusive language)
Additional information
Any non-breaking change, such as adding aliases, can be done in the scope of #36.
The problem/use-case that the feature addresses
As mentioned in #36, changing "master" and "slave" the replies of commands like ROLE and CLUSTER SHARDS are breaking changes. From feedback, we've learned that backward compatibility is more important than inclusive language.
Description of the feature
Opt-in for inclusive language. An idea is to use CLIENT CAPA introduced in #325. Idea:
CLIENT CAPA inclusive-languageCLIENT CAPA woke🤣CLIENT CAPA primary-replicaWhen a client has declared this capability, the server can send "primary" and "replica" in replies to ROLE and other commands.
Alternatives you've considered
Additional information
Any non-breaking change, such as adding aliases, can be done in the scope of #36.