Versioning
Dynoxide has two version numbers, and they are different on purpose.
The product version covers everything you install: the dynoxide CLI and its platform binaries, the npm packages, the browser engine, the container images, the GitHub Action and the Homebrew formula. dynoxide --version reports it, and so do the x-dynoxide-version and Server headers and the MCP server info.
The crate version covers dynoxide-rs on crates.io, and nothing else.
They were one number until 1.1.0. The split happened because a change to a public Rust type would otherwise have forced a major version on every artefact whose users never touch the Rust API, and moving everyone to ^2.x and dynoxide:2 to report a change they cannot observe is a poor trade.
Right now that means product 1.2.1, crate 2.0.1.
Which number do I want?
| If you are | Use |
|---|---|
Running npx dynoxide, Docker, Homebrew or the GitHub Action |
Product version |
Reading dynoxide --version output, or filing a bug report |
Product version |
Adding dynoxide-rs to a Cargo.toml |
Crate version |
Running cargo install dynoxide-rs --version X |
Crate version |
cargo install dynoxide-rs --version 1.2.1 will not find anything, because 1.2.1 is a product version. The Embedded SDK page renders its pin from crates.io, so copy it from there.
What moves which
A release can move one stream and leave the other alone. A Rust-only break publishes a new crate against an unchanged product; a CLI-only change publishes a new product against an unchanged crate.
| Change | Stream | Bump |
|---|---|---|
| Breaking change to a public Rust type or signature | Crate | major |
| Public Rust type or function added | Crate | minor |
| New feature flag, or an MSRV raise | Crate | minor |
| CLI flag removed or renamed | Product | major |
| HTTP response shape or error string change | Product | major |
| Container entrypoint or exposed port change | Product | major |
| Startup line text, or the stream it goes to | Product | major |
| Engine behaviour change | Both | major, unless it is a capture-backed conformance fix |
| New DynamoDB operation | Both | minor |
The MCP surface carries no version promise of its own. The data model is context for an agent rather than something the engine enforces, so serverInfo.version reports the product version, which is what you installed.
For the full rules, including how each contract is defined, see docs/versioning.md in the engine repository.