Check against your doze
Checking against doze
Kvrocks
OfficialSignedRedis API on RocksDB — durable, low-RAM.
doze/kvrocks$ doze add kvrocks- Newest
- 0.2.1 · 2 Jul 2026
- Needs
- any doze
- Runs
- Kvrocks 2
- Platforms
- macOS arm64 · Linux arm64 · Linux x86_64
- Licence
- Apache-2.0
- Source
- doze-modules
Versions
One release resolves. Nothing is ever taken down: a project pinned to any of them keeps working, and doze modules upgrade is the only thing that moves a pin.
Any doze, every release
- kvrocks 0.2.1Currentany dozeJul 2026. No oldest-doze field, so it runs on every doze, 0.1.0 and up.
The release tool writes the field from the SDK the module was built with, always as three numbers. A doze older than a release's minimum skips it and takes the newest release that fits.
doze 0.1.1 can't read a release's minimum doze. Update doze first, with brew upgrade doze, then run doze modules upgrade.
All releases
| Version | Released | Status | Needs doze | Protocol | Kvrocks | Platforms | Notes |
|---|---|---|---|---|---|---|---|
| 0.2 | 1 in the index · newest 0.2.1 | ||||||
| 0.2.1 | 2 Jul 2026 | Current | any doze | 1 | 2 | macarmx86 | |
No release matches these filters.
No download counts here: doze sends no telemetry, so nobody, including us, knows how often a release is fetched. Security advisories: none known for any release.
Not in the index
GitHub has older kvrocks builds than the registry lists. doze only resolves what the signed index names, so these can't land in a doze.lock.
- 0.1.0, 0.2.0On GitHub, never listed in the signed index.
- All files on GitHub
Upgrading a project
A project stays on the release in its doze.lock until you move it. Check first; the upgrade takes the newest release your doze can run, verifies it, and rewrites the pin.
$ doze modules upgrade --check$ doze modules upgrade kvrocksOn doze 0.1.1, update doze first: it can't read a release's minimum doze. Engine pins never move with a module upgrade.