VoltroDocumentation

Changelog

Where every released version is written down, what an entry tells you, and the stability contract to read before you pin a version.

Every released version of the @voltro/* packages is recorded, newest first, at docs.voltro.dev/changelog — filterable by package and by kind of change.

The same history travels with the code. It ships inside every package you install, so a deployment that pins versions by hand and never opens a browser still has it:

less node_modules/@voltro/cli/CHANGELOG.md

And in two machine-readable forms, for a dashboard, a bot or a release check:

curl -s https://docs.voltro.dev/changelog.json      # the whole history
curl -s https://docs.voltro.dev/changelog.xml       # an Atom feed of releases

What an entry tells you

Each entry carries four things, and you can act on all four without reading the prose underneath:

  • A headline — one line saying what changed.
  • A kind — Breaking, Added, Changed, Fixed, Removed or Internal.
  • The packages it touches, so a 70-package surface can be filtered down to the handful you depend on.
  • For a breaking change, how you are carried across it — the name of the codemod voltro update runs, or an explicit note that no user-authored code is affected.

Entries from earlier releases have no headline. Nothing was lost — the prose is complete — but those releases predate the field, and a summary invented after the fact would be a guess presented as a fact.

Read this before you pin a version

Voltro is 0.x — pre-1.0, and deliberately so. Under SemVer, 0.y.z means "anything MAY change", and that is exactly what is meant here:

  • Pin exact versions. Depend on @voltro/runtime@0.70.0, never ^0.70.0 or ~0.70.0. There is no compatible-range promise below 1.0.
  • Every minor may break. Breaking changes land on a minor bump (0.70.x → 0.71.0); patches (0.70.1 → 0.70.2) are additive or fixes only.
  • All packages release together. One coordinated version across the whole framework.
  • The changelog is the migration path. There is no deprecation cycle and no compatibility shim. The Breaking entries of each release are where a migration is written down.

Upgrading

voltro update bumps every @voltro/* dependency to the target version, aligns the @effect/* peers, and runs the codemods that ship with that version against your source:

voltro update

If you pin by hand and never run it, you can still print what it would have told you, without changing anything:

voltro update --codemods-only --from 0.68.0 --dry-run

Two releases have a written upgrade guide of their own, because they moved more than a changelog entry can carry: 0.34.0 and 0.38.0.