Hi raft-engine maintainers —
I'm one of the authors of mango, an in-progress Rust-native distributed key-value store (roughly: etcd's problem space, Rust implementation). We evaluated Rust Raft log-storage engines and chose tikv/raft-engine as our log-storage backend, with the following verified context:
- raft-engine has been TiKV's default Raft log since v6.1 (2022-06).
- The current
master branch is actively maintained (most recent commit 2026-03-10 at the time of our evaluation).
- The published crates.io release is
0.4.2 (2024-04-26), ~24 months behind master.
We've pinned via git + rev to the specific master SHA we vetted (alongside a cargo-vet entry and Renovate tracking on the master branch). That works for pre-1.0 mango, but the git-pin loses us cargo-audit's version-based advisory matching and makes version-aware tooling (Dependabot, RustSec) less useful for our downstream users.
Three questions:
- 1.0 plans. Is a 1.0 release on the roadmap, and if so, roughly on what timeline? We're not asking for a date — just whether it's an active intention or not currently prioritized.
- Semver commitment. Is
master currently considered semver-stable API (i.e., breaking changes would wait for 1.0), or does the pre-1.0 status mean breaking changes can land anytime?
- crates.io cadence. Is the gap between
0.4.2 and master a deliberate policy (e.g., publish only at TiKV release boundaries), or incidental? Would a cadence of "publish on master when breaking-change-free for N weeks" be acceptable?
We will link your response into our Architecture Decision Record (ADR 0002 §Risks) so downstream mango users have visibility into the log-storage engine's upstream health. No pressure on timeline — this is purely information-gathering for our own risk register.
Happy to contribute back any fixes we find during Phase 1 chaos testing.
Thanks for raft-engine — it's the most production-hardened Rust Raft log-storage I could find.
/cc mango ADR 0002
Hi raft-engine maintainers —
I'm one of the authors of mango, an in-progress Rust-native distributed key-value store (roughly: etcd's problem space, Rust implementation). We evaluated Rust Raft log-storage engines and chose
tikv/raft-engineas our log-storage backend, with the following verified context:masterbranch is actively maintained (most recent commit 2026-03-10 at the time of our evaluation).0.4.2(2024-04-26), ~24 months behind master.We've pinned via
git + revto the specific master SHA we vetted (alongside acargo-vetentry and Renovate tracking on the master branch). That works for pre-1.0 mango, but the git-pin loses uscargo-audit's version-based advisory matching and makes version-aware tooling (Dependabot, RustSec) less useful for our downstream users.Three questions:
mastercurrently considered semver-stable API (i.e., breaking changes would wait for 1.0), or does the pre-1.0 status mean breaking changes can land anytime?0.4.2andmastera deliberate policy (e.g., publish only at TiKV release boundaries), or incidental? Would a cadence of "publish on master when breaking-change-free for N weeks" be acceptable?We will link your response into our Architecture Decision Record (ADR 0002 §Risks) so downstream mango users have visibility into the log-storage engine's upstream health. No pressure on timeline — this is purely information-gathering for our own risk register.
Happy to contribute back any fixes we find during Phase 1 chaos testing.
Thanks for raft-engine — it's the most production-hardened Rust Raft log-storage I could find.
/cc mango ADR 0002