Closed madolson closed 7 months ago
Consider checking with Sidekiq - https://github.com/search?q=repo%3Asidekiq%2Fsidekiq%20redis_version&type=code
The maintainer of the framework may even agree to change the code to adapt to both standards but it will still be a problem for older versions of the library.
@romange Thx. We'll keep the redis_version
field and it will indicate the last Redis version we're compatible with.
In addition to that, we'll add server_name:valkey
and server_version:x.y.z
for the Valkey version. I don't think any clients break because of adding more fields, but it's theoretically possible so we might even wait until our next major release before adding them.
As far as I know, redis_mode
is used in many places:
StackExchange.Redis: Determine the startup mode through redis_mode
as standalone, cluster or sentinel. https://github.com/StackExchange/StackExchange.Redis/blob/main/src/StackExchange.Redis/ResultProcessor.cs#L872
Prometheus Exporter, use redis_mode
to display instance_info. https://github.com/oliver006/redis_exporter/blob/master/exporter/info.go#L168
I think we should start a separate thread to let sdk/tool developers report their commands or fields that depend on Redis. (If possible, the best approach is to not change these old fields)
I'm been thinking a bit about these new "server_version" and "server_name" fields in INFO. Ideally, services and forks based on valkey should be able to show their own names, e.g. "server_name:elastcache" or "server_name:foo" and then it may be useful to say which valkey version and which redis version it's compatible with.
One possibility is to follow redis style and just add "NAME_version" fields for each projects it's compatible with, like this:
server_name:quux
redis_version:7.2.4
valkey_version:8.2.0
quux_version:2025.B.29-rc23
It's not a clear idea, just a problem that we may want to solve before releasing these new fields.
Another possibility could be to use something like User-Agent string browser have, which the clients can parse if we introduce it and explain it from start, while keeping the legacy "redis_version" field, e.g.
redis_version:7.2.4
server:quux-2025.B.29-rc23/valkey-8.2.0/redis-7.2.4
A 3rd variant, something between the two above:
server_name:quux/valkey/redis
redis_version:7.2.4
valkey_version:8.2.0
quux_version:2025.B.29-rc23
The command
INFO
includes the following lines:Clients use this information to find out which version the server is running and from this they can conclude which features it supports.
The question is whether API compatibility justifies using a trademark name in the output of the command.
We have some alternatives: