Kyle J. Davis

So, say there is a change in client libs _and_ a new version of redis which makes whatever `strict` implementation no longer work. User configurable bits means something like this...

I'd like to avoid bundling modules, so option 3 (or maybe even looser). I don't like option 1. It picks winners. Say, I create a module that uppercases a string...

Something mildly interesting that the PR number on this is `386` and it's about biggest platform that doesn't (currently) use an x86 architecture.

> finally remove all master/slave terminology +1 this is the right time start this.

@zuiderkwast I get the 7.x line strategy. But otherwise i'm a bit confused. You bring up 8.x but this [conversation says starting with 10](https://github.com/orgs/valkey-io/discussions/31). Did that get decided somewhere else?...

Just discovered this issue 🤦 Tomorrow (7/28) there is an open session on this topic - see this [discussion](https://github.com/runfinch/finch/discussions/479)

If there is a compat knob, it would be good to have a pre-determined sequence of deprecation. E.g. version `n` introduce knob and optional new terminology, version `n+1` new terminology...

3 major version would be enough transition time, I'd assume. But mainly I'm just advocating have a set plan before changes happen so it doesn't languish for an undetermined amount...

Looks like node_redis was re-written in typescript (🙄) and they removed a bunch of stuff. Try pegging the node_redis version to v3. Or appealing to the folks over in node_redis...

I really like this idea and [I've had a similar thought in the past](https://fosstodon.org/@linux_mclinuxface/109569808911455248). Here is my brain dump. **Mapping of a model site to mastodon** It feels like most...