Changelog

Release notes live in CHANGELOG.md. Each version’s section there is what its GitHub release says — the release workflow copies it across, and a tag with no section does not release at all.

Where the versions themselves are:

• GitHub releases — one entry per version, with the prebuilt ezu binaries attached.
• crates.io — published versions of every crate.
• npm — the WebAssembly package, versioned in lockstep with the crates.

What the version numbers mean

Every published crate in the workspace shares one version and is released as a set, so ezu 0.10.0 expects ezu-graph 0.10.0. Pin the umbrella crate and let it pin the rest.

ezu is pre-1.0, so a minor bump may contain a breaking change — to the Rust API, to the style spec, or to the wasm interface. In practice:

• patch (0.6.0 → 0.6.1) — fixes, no interface change intended.
• minor (0.6.x → 0.7.0) — new capabilities, and any breaking change.

maplibre-expr lives in its own repository and versions independently.

Style spec changes

The style language is versioned with the workspace. A change to the document shape — a renamed field, a new required field, a changed default — is called out in the release notes for the version that introduces it.

Two things make an upgrade cheap to check:

ezu check style.json --no-fetch     # every style you own, against the new binary
ezu schema --out ezu-style.schema.json   # regenerate the schema your editor uses

The schema is assembled from the op registry, so regenerating it after an upgrade is how you see, concretely, what changed in the ops you use.

The version field in a document

{ "name": "watercolor", "version": "1", "…": "…" }

That field is yours. Nothing in ezu reads it. It is there so a style can carry its own version alongside its name — useful as part of a tile cache key.