Changelog

Zuke isn't one artifact with one version. It's 58 packages — @zuke/core, the @zuke/cli command, a generic @zuke/cmd fallback, and 50+ typed tool wrappers and plugins — each published independently to JSR with its own semantic version. There is no single "Zuke version", so this page describes the release model and links to the authoritative notes rather than duplicating a version history that would go stale. For what each package's version promises — and how the @zuke/core floors interlock — see Versioning & compatibility.

The release model

Releases are automated end to end by release-please, driven by Zuke's own build. The flow is:

Work lands on master as Conventional Commits (feat:, fix:, feat!: / BREAKING CHANGE:).
release-please maintains a single release PR covering every package with pending changes. It bumps the version in each package's deno.json, writes that package's own CHANGELOG.md, and updates the manifest.
Merging the release PR tags each release (<component>-v<version>) and cuts the GitHub releases.
Zuke then publishes itself to JSR: the publish target walks the packages core-first and publishes each one whose version isn't yet on JSR. Authentication is OIDC — the JSR package ↔ repo link means no tokens are involved.
The same release finally syncs this website: it regenerates llms.txt, llms-full.txt, the API reference data, and the package catalog, then opens and auto-merges a PR against this repository. So the generated pages here never lag a release.

Because versions are per-package and each package carries its own changelog, the per-tag entries on the tracker below are the real record.

core-v1.56.0   # @zuke/core
cli-v1.0.0        # @zuke/cli
ai-v1.8.1         # @zuke/ai

Zuke builds, tests, and releases itself — the repository's own zuke.ts runs the full gate and drives release-please, JSR publishing, and this site's sync — the same build declares its own pipeline.

Milestones

The per-package changelogs are generated; these are the project-level moments worth knowing about.

Date Milestone

2026-07-30 Every package reached 1.0.0. All 58 packages are now 1.x — there is no pre-1.0 tier left. @zuke/tsgo was dropped in the same change: TypeScript 7.0 ships the native Go compiler as the tsc of the ordinary typescript package, so @zuke/tsc already drives it. (To drive the tsgo nightly instead, point the tsc wrapper's toolPath at node_modules/.bin/tsgo — the CLI surface is the same.)

2026-06-22 @zuke/core 1.0.0 — the first stable release of the build library: the typed target graph, the injection-safe $ shell, FileTasks, the built-in coverage gate, and code-first CI generation.

Date	Milestone
`2026-07-30`	Every package reached `1.0.0`. All 58 packages are now `1.x` — there is no pre-1.0 tier left. `@zuke/tsgo` was dropped in the same change: TypeScript 7.0 ships the native Go compiler as the `tsc` of the ordinary `typescript` package, so `@zuke/tsc` already drives it. (To drive the `tsgo` nightly instead, point the `tsc` wrapper's `toolPath` at `node_modules/.bin/tsgo` — the CLI surface is the same.)
`2026-06-22`	`@zuke/core` 1.0.0 — the first stable release of the build library: the typed target graph, the injection-safe `$` shell, `FileTasks`, the built-in coverage gate, and code-first CI generation.

The full list lives in the repository's root CHANGELOG.md.

How versions move

All 58 packages are 1.x and make the same promise. release-please runs with bump-minor-pre-major off, so nothing ships a breaking change under a minor bump: a 1.x release never breaks a public symbol, and a breaking change bumps the major version. Depend on jsr:@zuke/<package>@^1 and take minors without reading the diff.

What a wrapper's 1.x promise does not cover is the upstream CLI it drives. When a tool renames or drops a flag, the wrapper either keeps the old method working (deprecated) or bumps its own major — the promise is about the wrapper's typed surface, not upstream's stability. Read a package's CHANGELOG.md when its major moves; that is the only release that can require a code change on your side. See Versioning & compatibility for the @zuke/core floor each wrapper declares.

Where the release notes live

There is no hand-maintained master changelog to read here — the per-package notes are generated, and these are the authoritative sources:

Source	What it has
GitHub Releases	every tagged release, per package, with the generated notes — the primary record of what changed and when
JSR — `@zuke`	the live version of every published package, plus its docs and download stats
Root `CHANGELOG.md`	project-level milestones — the entries summarised above

Pinning a version

Zuke is imported by URL, so the version is part of the import specifier. Track the major line and let patches and non-breaking minors resolve; pin an exact version only when you need a byte-for-byte reproducible import specifier.

// Track the latest of a major line (recommended):
import { Build, run, target } from "jsr:@zuke/core@^1";

// Or pin an exact version for a fully reproducible build:
import { Build, run, target } from "jsr:@zuke/core@1.56.0";

Always commit deno.lock. The caret range in deno.json only bounds what is allowed; the lockfile fixes what is actually used, for @zuke/core and every wrapper. Regenerate it when you deliberately take an upgrade, and review the diff.

See Getting started for setting Zuke up in a project, Versioning & compatibility for the per-package promise, and Tools for the wrapper packages each versioned separately.