The output of INFO server

[madolson]

The command INFO includes the following lines:

# Server
redis_version:255.255.255
redis_git_sha1:daadbca2
redis_git_dirty:1
redis_build_id:187c43196ce2ead2
redis_mode:standalone

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:

1. Change "redis_version" to "server_version" (etc.) and also add a "server_name:newname"
2. Change the prefix, e.g. "newname_version", etc.
3. Keep the existing output.

[romange]

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]

Also https://github.com/StackExchange/StackExchange.Redis/blob/2f69707d87488febb7376739ed4dc51ad9a422c6/src/StackExchange.Redis/ResultProcessor.cs#L864

[zuiderkwast]

@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.

[yangbodong22011]

As far as I know, redis_mode is used in many places:

1. 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

2. 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)

[zuiderkwast]

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