Changelog

Zuke isn't one artifact with one version. It's 55 packages — @zuke/core, the @zuke/cli command, a generic @zuke/cmd fallback, and 50+ typed tool wrappers — 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.

The release model

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

  1. Work lands on master as Conventional Commits (feat:, fix:, feat!: / BREAKING CHANGE:).
  2. 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.
  3. Merging the release PR tags each release (<component>-v<version>) and cuts the GitHub releases.
  4. 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.

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.30.2      # @zuke/core
cli-v0.7.0        # @zuke/cli
ai-v1.6.0         # @zuke/ai

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

Current headline versions

A snapshot of a few key packages. These move independently — this table is a point-in-time reference, not a coupled release set — so always check JSR for the live number of any package.

PackageVersionRole
@zuke/core1.30.2the build library — the typed target graph, parameters, secrets, and reporter
@zuke/cli0.7.0the zuke command that discovers and runs a build
@zuke/cmd0.3.2the generic command wrapper — the fallback for any tool without a dedicated package
@zuke/deno0.6.1Deno tool wrapper (DenoTasks)
@zuke/ai1.6.0AI-assisted build helpers
@zuke/console1.0.1the console reporter
@zuke/otel1.0.1OpenTelemetry reporter

@zuke/core reached its first stable 1.0.0 on 2026-06-22 and follows semantic versioning from there — depend on ^1 with confidence.

How versions move

release-please runs with bump-minor-pre-major enabled, which changes what a breaking change does depending on whether a package has reached 1.0:

  • A package still in 0.x (most tool wrappers) takes a minor bump on a breaking change and stays in 0.x. Treat any 0.x minor as potentially breaking.
  • A package that has reached 1.0 — @zuke/core, plus @zuke/ai, @zuke/console, @zuke/otel, and others — follows full semver: a breaking change bumps the major version.

So a @zuke/core minor is always additive and safe under ^1, whereas a tool wrapper's minor may not be. Pin accordingly.

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:

SourceWhat 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

Pinning a version

Zuke is imported by URL, so the version is part of the import specifier. For a stable package, tracking a major line gives you fixes and additions automatically; pin an exact version when you need a byte-for-byte reproducible build. 

// 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.30.2";

See Getting started for setting Zuke up in a project, and Tools for the wrapper packages each versioned separately above.