The output of INFO server about valkey HOT 5 CLOSED

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.

from valkey.

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

from valkey.

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)

from valkey.

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

from valkey.

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

from valkey.