# Redis 6.0.0 GA is out!

DevFeed: [Redis 6.0.0 GA is out!](<https://devfeed.tech/articles/redis-6-0-0-ga-is-out-20623.md>)

Original publisher: [Read original article](<http://antirez.com/news/132>)

Published: 2020-04-30T13:33:35Z

Content type: release

Language: en

Sources: [Antirez](<https://devfeed.tech/sources/antirez.md>)

Topics: [Redis](<https://devfeed.tech/topics/redis.md>), [Caching](<https://devfeed.tech/topics/caching.md>), [Replication](<https://devfeed.tech/topics/replication.md>), [Benchmark](<https://devfeed.tech/topics/benchmark.md>)

Tags: [benchmark](<https://devfeed.tech/tags/benchmark.md>), [cache](<https://devfeed.tech/tags/cache.md>), [caching](<https://devfeed.tech/tags/caching.md>), [redis](<https://devfeed.tech/tags/redis.md>), [release](<https://devfeed.tech/tags/release.md>), [replication](<https://devfeed.tech/tags/replication.md>), [server](<https://devfeed.tech/tags/server.md>)

## AI overview

Redis 6.0.0 has reached stable release. The article reviews its previously announced features and highlights changes to client-side caching, including key-name-based caching, broadcasting mode, and opt-in or opt-out invalidation behavior.

## Source excerpt

Finally Redis 6.0.0 stable is out. This time it was a relatively short cycle between the release of the first release candidate and the final release of a stable version. It took about four months, that is not a small amount of time, but is not a lot compared to our past records :) So the big news are the ones announced before, but with some notable changes. The old stuff are: SSL, ACLs, RESP3, Client side caching, Threaded I/O, Diskless replication on replicas, Cluster support in Redis-benchmark and improved redis-cli cluster support, Disque in beta as a module of Redis, and the Redis Cluster Proxy (now at https://github.com/RedisLabs/redis-cluster-proxy). So what changed between RC1 and today, other than stability? 1. Client side caching was redesigned in certain aspects, especially the caching slot approach was discarded in favor of just using key names. After analyzing the alternatives, with the help of other Redis core team members, in the end this approach looks better. Other than that, finally the feature was completed with the things I had in the backlog for the feature, especially the "broadcasting mode", that I believe will be one of the most popular usage modes of the feature. When broadcasting is used, the server no longer try to remember what keys each client requested. Instead clients subscribe to key prefixes: they'll get notifications every time a key matching the prefix is modified. This means more messages (but only for the selected prefixes), but no memory effort in the server side. Moreover the opt-in / opt-out mode is now supported, so it is possible for clients not using the broadcasting mode, to exactly tell the server about what the client will cache, to reduce the number of invalidation messages. Basically the feature is now much better both when a low-memory mode is needed, and when a very selective (low-bandwidth) mode is needed. 2. This was an old request by many users. Now Redis supports a mode where RDB files used for replication are im