[NEW] The great un-deprecation

[stockholmux]

The problem/use-case that the feature addresses

There are 25 commands that are deprecated in Valkey today. The approach to the API for the Valkey project has somewhat diverged from the project it forked from. Valkey has a strong commitment to not break existing code by removing deprecated commands.

Consequently, for most of these deprecated commands they remain fully supported and functional in Valkey and will remain so. For these commands, the deprecation designation has little value and is just a point of confusion.

Description of the feature

I would like to un-deprecate the following commands:

• QUIT
• GEORADIUS
• GEORADIUSBYMEMBER
• GEORADIUSBYMEMBER_RO
• GEORADIUS_RO
• HMSET
• BRPOPLPUSH
• RPOPLPUSH
• SLOWLOG
• SLOWLOG GET
• SLOWLOG HELP
• SLOWLOG LEN
• SLOWLOG RESET
• ZRANGEBYLEX
• ZRANGEBYSCORE
• ZREVRANGE
• ZREVRANGEBYLEX
• ZREVRANGEBYSCORE
• GETSET
• PSETEX
• SETEX
• SETNX
• SUBSTR

Since many of these commands have functionality that can be achieved by another command with an argument, the documentation would state that it's "Similar to" instead of "Deprecation advice".

Additionally, it might be worth writing up the API philosophy for Valkey as a guiding document.

Alternatives you've considered

Do nothing.

Additional information

n/a

[ranshid]

I agree this makes sense (specifically regarding the quit command which I am not sure why it was decided to be deprecated).

Question: does it mean we decide to STOP deprecating commands in the future as well? What will be the rules and guidelines to deprecate commands in the future then?

[stockholmux]

@ranshid I'd love to hear other's opinions, but in my mind, no, this doesn't prevent future deprecation (and there will still be a handful of deprecated commands after the list above).

However, I think we need to define a specific set of circumstances where we'll deprecate and what that means.

For example, if there was a command that had a substantial performance advantage but a slight behaviour change, then you could deprecate the original command.

Additionally, we should have a relatively high bar to deprecate and a set of processes to communicate the change. Many of the currently deprecated commands seem to have scant traces on the reasoning why they were deprecated originally (and often it felt like the bar was 'vibes').