Files
zeekayandHanzo Dev 1ad510e19d refactor: follow hanzokv/go v9.22.0 package rename redis -> kv
github.com/hanzokv/go/v9 v9.22.0 renamed its Go package from "redis" to
"kv"; the import path is unchanged. A lock library is typed against the
client it wraps -- the adapter's NewPool takes the client's
UniversalClient and compares against the client's Nil sentinel -- so the
qualifier change is load bearing, not cosmetic.

Client-driven:

- go.mod: github.com/hanzokv/go/v9 v9.21.1 -> v9.22.0
- the adapter for our client speaks kv.UniversalClient / kv.Nil, imported
  unaliased as in hanzokv/go's own sources

Our own vocabulary follows:

- redis/ -> kv/, package redis -> package kv. This is redsync's own
  Pool/Conn/Script abstraction over a KV backend, not anyone's product.
- redis/goredis/v9 -> kv/kvgo (package kvgo). That adapter wraps
  hanzokv/go, not go-redis; the old name said the wrong thing. Its
  example moves with it: examples/goredis/v9 -> examples/kvgo.
- import alias redsyncredis -> redsynckv
- RedisError -> KVError (and its tests)
- comments and README speak kv

Deliberately NOT renamed, because they name foreign things:

- the redigo, rueidis, valkeygo and go-redis v6/v7/v8 adapters, which
  target genuinely different clients, keep their names and their own
  "redis." qualifiers (redigo's redis.Conn, go-redis's redis.Nil)
- the server-side Lua in scripts.go: redis.call is the store's scripting
  API. Rewriting it would change the script source and therefore the
  SHA1 hashes pinned in scripts.go, which TestScripts_Hash verifies
  against a live server.
- upstream links (redis.io distlock post, redigo attribution)

Import paths move from .../v4/redis/... to .../v4/kv/...; the module
major stays v4 by policy.

Verified with a local redis-server: go build ./..., go vet ./...,
go test -count=1 ./... and go test -race -count=1 ./... all pass,
TestScripts_Hash included.

Co-authored-by: Hanzo Dev <[email protected]>
2026-07-26 08:53:51 -07:00
..