valkey
valkey copied to clipboard
Long term Valkey compat strategy
~~Per discussion in https://github.com/valkey-io/valkey/issues/43, we should consider tackling (more) compat issues holistically in RC2.~~
IMO, I think we should break as much as we like in ~~RC2~~ the first major release and only, which includes changing the server ident from "redis" to "valkey", replacing "master/slave" with "primary/replica", etc in all user facing areas. All these changes should be gated upon a compat knob, which could be binary (on vs off) or a bit more granular (strict/loose/none) but shouldn't be more granular than that. After achieving this in ~~RC2~~ the first major release, I think we should agree on a timeline to completely remove this compat layer (in 1-2 years or major releases, ideally).
I don't have the details yet, such as whether this compat knob is compile time, build time or packaging time, and what does "loose" mean, etc. I am curious to hear the community's thoughts on the high level direction.
@valkey-io/core-team
I don't think this should be the release candidate 2 of 7.2, which is what I said about rc2. I feel like this should the first major release of valkey, which includes clear deprecation plan for all the features. The release candidates for 7.2 should only be redis 7.2 compatible. It seems like trying to push a lot of compatibility stuff into 7.2 doesn't make sense that much sense to me.
Agreed. I am aligned with dealing with compat in a major release.
Let me retitle this thread and update my first comment next and we continue the 7.2 discussion in https://github.com/valkey-io/valkey/issues/43.
Regarding the compatibility aspects of Valkey with Redis, I would like to inquire about the community's thoughts:
- Will Valkey remain compatible with Redis? I've read some discussions in #43, and I understand that the initial version will definitely be compatible, but what about later versions? For example, in subsequent versions, is it possible to migrate from Redis to valkey, or from valkey to Redis?
- My main concern is about the compatibility of persistent data (configuration files, AOF, RDB, etc.) and the module interfaces. This may affect the community's acceptance of new features in the future.
@bugwz We will remain compatible with redis 7.2, but we don't know what redis will add in the future. It's impossible to promise to be compatible with future redis versions.
@PingXie Do we need to do anything else about this item? Should we documented it explicitly somewhere?
Should we documented it explicitly somewhere?
I like this idea. Maybe we can start curating a section on the documentation site and start adding behavior differences from 7.2, if any. I also see that we might start adding materials about behavior differences from future Redis versions.