Versioning and server info

[alisaifee]

Currently dragonfly returns the following information in response to INFO SERVER:

# Server
redis_version:df-v0.2.0
redis_mode:standalone
arch_bits:64
multiplexing_api:iouring
tcp_port:6379
uptime_in_seconds:1150
uptime_in_days:0

and for HELLO:

 1) "server"
 2) "redis"
 3) "version"
 4) "df-v0.2.0"
 5) "proto"
 6) (integer) 2
 7) "id"
 8) (integer) 185
 9) "mode"
10) "standalone"
11) "role"
12) "master"

At least for one client library (the one I maintain, obviously 😁) the version results in two (minor, workaround-able) problems:

1. it can't be parsed as a valid version
2. it complains about certain features or commands that are mapped to specific minimum redis server versions.

Now these can easily be managed with workarounds but it made me wonder if there's any benefits of:

• Maintaining a separate compatibility version string for redis_version that actually references a maj.minor version of redis itself to map dragonfly's api compatibility
• Identifying the server as dragonfly instead of redis in the response to HELLO and perhaps even adding extra details in the response to INFO?

[romange]

It's easier to answer regarding HELLO first.
If answering as dragonfly won't cause problems to the existing clients (redis-py, nodejs etc) I am not against it. What I want to avoid is that we break compatibility because of it.

Re info/version: I do not mind having a compatibility version as long as we have dragonfly_version as well.
How Keydb solved this? Did they maintain the same version as redis?
re - adding more extra details, what did you have in mind? dragonfly_version ?

[alisaifee]

Keydb identifies as server=redis in the response to HELLO. However, keydb's versioning looks like it tries to maintain a parity with redis (which makes sense as it's a fork).

Regarding compatibility (and specifically the use of HELLO) - I don't think any client libraries would be making use of the information in the server field unless they are aware / cater to a variant implementation (needs verification). For Keydb I would argue that would actually be useful since the server exposes new commands that don't exist in redis.

At the moment I could only think of dragonfly_version (which assumes that redis_version will have a different meaning). KeyDB actually has an extra section KeyDB in the response to INFO which at the moment contains details about the mvcc.

[romange]

Sounds like we are on the same page then. What would we put in redis_version? 2.8 ?

re sections, yes we also have our special sections, they are exposed with info all command.