The bundled GitHub Actions workflows now use Node 24-compatible action versions, which keeps CI, release, and publishing automation aligned with GitHub's runtime transition. The release and sync workflows also mint GitHub App installation tokens without relying on a deprecated JavaScript action.
Release commands and the Python API now handle release versions more consistently when changelog data mixes tag-style versions such as v1.2.3 with bare semantic versions such as 1.2.3. This improves compatibility with existing changelog histories and makes release automation more reliable across commands that inspect, create, show, and publish releases.
init command scaffolds changelog projects interactively or non-interactively, so you can set up a standalone or package-based project in less time. It also protects existing projects from accidental overwrites.
A new init command allows for scaffolding a new changelog project interactively or with the --yes flag. It supports both standalone and package modes, and prevents accidental overwriting of existing projects.
tenzir-ship init
This reduces the manual effort required to set up a new changelog.
]]>Mar 4, 2026 · @mavam, @claude, @codex
We improved clarity and efficacy of the releasing process in the tenzir-ship agent skill.
Mar 1, 2026 · @mavam, @claude, @codex · #11
The pi-tenzir-ship package provides a skill for AI coding agents to perform
release engineering tasks. Install it in Pi with:
pi install npm:pi-tenzir-ship
Then activate it with /skill:tenzir-ship.
The skill covers adding changelog entries, cutting standard and module releases, triggering GitHub Actions release workflows, and publishing releases to GitHub.
Feb 28, 2026 · @mavam, @codex · #10
The release creation command now automatically updates version fields in package manifest files during release. When creating a release, tenzir-ship detects and updates package.json, pyproject.toml, project.toml, and Cargo.toml files in your project, including support for dynamic version files in monorepo workspaces.
You can control this behavior with the release.version_bump_mode configuration option in your config.yaml:
auto (default): Automatically detect and update version filesoff: Skip version file updatesFor more granular control, use the release.version_files option to explicitly specify which files to update. Auto-detection searches the project root and parent directory (for nested changelog projects) and gracefully skips files without static version fields.
Release version selection now defaults to automatic bumping when you run
release create without an explicit version and without --patch, --minor,
or --major. The next version is inferred from unreleased entry types:
If no unreleased changelog entries exist, automatic bumping is not available. In that case, provide an explicit version or a manual bump flag to create an intro-only release.
The stats command now reports the computed next release version (or no value
when no automatic bump can be inferred), including in stats --json.
Feb 28, 2026 · @mavam, @codex · #9
Create releases with only introductory text and no changelog entries by using the --intro or --intro-file flags with release create. This is useful when re-publishing a package after yanking a previous artifact or retrying a failed publish workflow—scenarios where you want to create a new release version without adding changelog entries.
Previously, you had to provide at least one changelog entry to create a release. Now the release creation allows you to skip the entries entirely if you supply intro text. The --intro flag accepts text directly, while --intro-file reads from a Markdown file.
reusable-release.yaml now acts as a minimal opinionated wrapper around a new
reusable-release-advanced.yaml workflow.
The advanced workflow adds optional hooks and release controls for complex
consumers: pre/post publish scripts, non-main --no-latest publishing,
optional copy of release directories to main, latest branch updates, a
skip-publish dry-run mode, and workflow outputs for version and
is_latest.
Release commands now validate changelog directory structure before they run and fail fast when it is invalid.
release create and release publish now stop with explicit errors when stray files or directories are detected (for example, an unexpected changelog/next/ directory). Other commands (show, add, stats, and release version) emit warnings so layout problems are visible earlier, while validate reports full structural issues as regular validation errors.
Feb 15, 2026 · @mavam, @claude · #7
When a release step fails, the full command now prints below the progress panel so you can copy-paste it for manual recovery.
Previously, long commands would get truncated in the release progress panel, making it difficult to reproduce the failure manually. Now when a step fails, the complete command is displayed in full below the panel, giving you what you need to debug and retry the operation.
]]>authors field now correctly normalizes single string values, and the show command no longer misidentifies entry IDs as release versions.
Jan 26, 2026 · @mavam, @claude
The show command no longer misidentifies changelog entry IDs as release versions. Previously, entries with IDs containing version-like patterns (e.g., v1...) were incorrectly treated as releases.
Jan 26, 2026 · @mavam, @claude
Changelog entries with authors: "name" (a single string) are now correctly normalized to a list. Previously, only the singular author key was normalized, which could cause rendering issues when authors was used with a string value.
show command now displays entries in consistent chronological order, and release recovery instructions show the actual branch name instead of a placeholder.
Jan 22, 2026 · @mavam, @claude · #6
The multi-project show command now displays changelog entries in chronological order, with the newest entry at the bottom of the table where users expect it. Previously, entries were sorted newest-first, which was inconsistent with single-project behavior and user expectations. This brings the multi-project display in line with the rest of the application's sorting behavior.
Jan 22, 2026 · @mavam, @claude · #5
When a release fails during the branch push step, the recovery instructions now display the actual branch name instead of a placeholder:
╭──────────────────── Release Progress (2/5) ────────────────────╮
│ ✔ git commit -m "Release v1.2.0" │
│ ✔ git tag -a v1.2.0 -m "Release v1.2.0" │
│ ✘ git push origin main:main │
│ ○ git push origin v1.2.0 │
│ ○ gh release create v1.2.0 --repo tenzir/ship ... │
╰────────────────────────────────────────────────────────────────╯
Previously, the failed step showed git push origin <branch>:<branch> instead
of the actual branch name.
release publish encounters
failures mid-workflow. You now see a clear progress summary showing which steps
completed, which step failed, and what remains pending—making recovery
straightforward.
Jan 17, 2026 · @mavam, @claude
The release publish command now displays a progress summary when a step fails mid-workflow, showing which steps completed successfully and which step failed.
When using --commit or --tag flags, the publish workflow executes multiple git operations (commit, tag, push branch, push tag) before publishing to GitHub. If any step fails, you now see a panel with checkmarks for completed steps, an X for the failed step, and circles for pending steps. This helps you understand exactly where the workflow stopped and what manual commands you need to run to recover.
For example, if the branch push fails due to network issues, you'll see that the commit and tag were created successfully, the push failed, and the tag push and GitHub publish are still pending—making it clear you can safely retry after fixing the network issue.
]]>tenzir-changelog to tenzir-ship and introduces several breaking changes to streamline the CLI interface. The show command now uses intuitive positional tokens (unreleased, released, latest, all) instead of flags, and the release notes command has been merged into show --release. A new stats command provides adaptive project statistics, and the table layout has been enhanced with better title formatting and inline component labels.
The show command now uses positional scope tokens instead of flags to filter entries. The --all, --released, --unreleased, and --latest flags have been removed in favor of cleaner positional identifiers.
Use show unreleased, show released, show latest, or show all to filter entries by scope. The --release flag now purely controls presentation (grouping and metadata display) rather than affecting which entries are shown.
This change provides clearer separation between what to show (scope) and how to show it (presentation), making the command interface more intuitive.
Breaking change: show --release without identifiers now shows all entries grouped by release, whereas previously it defaulted to showing only the latest release. Use show latest --release to restore the previous behavior.
Migration examples:
show --unreleased → show unreleasedshow --released → show releasedshow --latest → show latestshow --all → show all or just showshow --release → show latest --release (to get previous behavior)show --release --latest → show latest --releaseThe project has been renamed from tenzir-changelog to tenzir-ship. This includes the package name, CLI command, Python module, and GitHub repository.
Migration:
# Old
uvx tenzir-changelog add
# New
uvx tenzir-ship add
# Old
from tenzir_changelog import Changelog
# New
from tenzir_ship import Changelog
All command names remain unchanged (add, show, validate, release). The repository has moved from tenzir/changelog to tenzir/ship.
The old tenzir-changelog PyPI package will remain available for a transition period but will not receive further updates.
The modules command has been removed. Use the --show-modules global option instead to list discovered modules.
Migration:
# Before
tenzir-changelog modules
# After
tenzir-changelog --show-modules
The PATH column now displays clean relative paths (for example, plugins/brand/changelog) instead of paths with ../ prefixes (for example, ../plugins/brand/changelog).
The release notes command has been removed and replaced by the unified show
command with new --release, --all, and --released-only flags.
Previously, the CLI had two overlapping commands with different mental models:
show displayed entries in a flat list, while release notes formatted them
as release documents. This caused confusion because both produced similar JSON
output for single releases but had different defaults and use cases.
The new design follows a single principle: selection is always entry-centric,
and --release is a display modifier. Version identifiers like v1.0.0 mean
"entries from release v1.0.0", and the --release flag changes how those
entries are presented—grouped by release with full metadata—rather than what
gets selected.
Migration guide:
| Old command | New command |
| ----------------------------- | ------------------------------ |
| release notes v1.0.0 | show v1.0.0 --release -m |
| release notes v1.0.0 --json | show v1.0.0 --release --json |
| release notes - | show --release -m |
| release notes - --json | show --release --json |
New capabilities: The --all flag enables batch export of all releases in a
single invocation.
# Export all releases as JSON (new)
tenzir-changelog show --all --release --json
# Export only released versions, excluding unreleased
tenzir-changelog show --all --release --released-only --json
This is particularly valuable for documentation sync scripts that previously required invoking the tool once per release. With ~320 releases across 7 projects, the sync time drops from ~2 minutes to ~2-3 seconds.
JSON output consistency: With --release, JSON output is always an array of
release objects, even for a single release. This ensures deterministic parsing
in scripts.
[
{
"version": "v1.0.0",
"title": "Release Title",
"intro": "Release introduction...",
"entries": [...]
}
]
Without --release, JSON remains a single object with a flat entries array.
The stats command replaces the --stats flag and automatically adapts its display based on project structure. For single projects, it shows a vertical card view with detailed statistics organized into sections (Project, Releases, Entry Types, Entry Status). For multi-module projects, it displays a compact table comparing all modules side-by-side.
The vertical view presents project metadata, release history with exponentially weighted cadence calculations, entry type distribution with percentages, and shipped vs unreleased counts. The table view uses emoji headers for consistent visual scanning across both formats.
Additional options include --table to force table view regardless of project structure, and --json to export structured data for programmatic consumption.
The title column now expands to fill available terminal width, ensuring optimal use of screen space. Component labels appear inline after the title in a dimmed green style, replacing the separate component column. The column order has been adjusted to show PR numbers before the entry type, and the column header changed from "PRs" to "PR". Empty PR values display as a dimmed dash for visual consistency.
Markdown tables in release notes and entry descriptions now render correctly. Previously, tables were collapsed into a single line because the normalize_markdown() function lacked GFM (GitHub Flavored Markdown) support.
The fix adds the mdformat-gfm plugin to enable proper table formatting. This ensures migration guides, comparison tables, and other tabular content display as intended in both CLI output and exported markdown files.
When creating the first release, you can now use --major, --minor, or
--patch flags without an existing release. The tool uses an implicit 0.0.0
as the base version:
--major creates 1.0.0--minor creates 0.1.0--patch creates 0.0.1Previously, these flags required at least one prior release, forcing users to always specify an explicit version for their first release.
Dec 22, 2025 · @mavam, @claude
Row numbers in multi-project table view now count down from the newest entry, matching single-project behavior. The show -c <row> command also resolves row numbers correctly against the displayed table.
Dec 30, 2025 · @mavam, @claude
Add omit_pr and omit_author configuration options to prevent automatic inference of PR numbers and authors. When these config options are set to true, the add command will not auto-detect PR numbers from git branches or infer authors from git commits. If users explicitly provide --pr or --author flags while the corresponding omit option is enabled, a warning message is emitted and the value is ignored. This gives projects fine-grained control over changelog entry metadata.
config.yaml that applies across all commands.
Dec 24, 2025 · @mavam, @claude
The explicit_links option can now be configured in config.yaml, allowing consistent link formatting across all commands that render release notes and changelog entries.
Previously, the --explicit-links flag only worked with the release create command and had no persistent setting. Now you can set explicit_links: true in your project's config.yaml to enable explicit Markdown link rendering by default for all commands (release create, release notes, and show). Individual command invocations can still override the config default with --explicit-links or --no-explicit-links flags.
This ensures consistent output across commands without requiring repeated flag usage, improving the user experience for projects that always want explicit link rendering.
]]>Dec 24, 2025 · @mavam, @claude
Add --explicit-links flag to the release create command to convert GitHub shorthand (@mentions and #PR references) into explicit Markdown links.
This flag enables exporting release notes to documentation sites or other Markdown renderers that don't automatically link GitHub references. To maintain consistency across the CLI, the option is now shared between release create, release notes, and show commands via dedicated option decorators.
The Python API's Changelog.release_create() method now accepts an explicit_links parameter to support this feature programmatically.
Dec 21, 2025 · @mavam, @claude
The release publish command now accepts the version as an optional argument, defaulting to the latest released version when omitted. This makes it easier to publish the most recent release without explicitly specifying its version.
A new release version command prints the latest released version. The --bare flag strips the v prefix, making it convenient for version-agnostic workflows that need to reference the release version in scripts or CI/CD pipelines.
Additionally, release version validation has been strengthened to ensure semantic versioning compliance.
Dec 21, 2025 · @mavam, @claude
The show command now sorts entries by date across all modules, placing the latest entries at the bottom of the table. Previously, entries were grouped by project first, which scattered recent changes throughout the output based on module name order.
Dec 21, 2025 · @mavam, @claude
Release notes no longer include an H1 heading in the markdown content. GitHub already displays the release title as a page header, so having it inside the notes caused duplication.
]]>release create.
Dec 21, 2025 · @mavam, @claude
Status messages now emit to stderr, allowing scripts to capture machine output from stdout without ANSI-colored status lines interfering.
Previously, commands like release create wrote both status messages and the version string to stdout, breaking workflows that capture output via VERSION=$(uvx tenzir-changelog release create ...).
release create output the version to stdout. All Rich UI elements now go to stderr, enabling clean machine-readable results for automation workflows.
Dec 19, 2025 · @mavam, @claude
The release create command now outputs the created version to stdout, enabling shell scripting patterns like VERSION=$(tenzir-changelog release create --minor --yes). All Rich output (tables, panels) now goes to stderr, keeping stdout clean for machine-readable results.
Dec 19, 2025 · @mavam, @claude
For projects with modules, parent releases now automatically include a summary of module changes. Each parent release manifest records the module versions at release time, enabling incremental tracking—subsequent releases only show new module entries since the previous parent release.
Module summaries appear after the main changelog, separated by a horizontal rule. Each module section shows its version and lists entries in compact format: emoji prefix, title, and byline.
Dec 19, 2025 · @mavam, @claude
The JSON output of release notes --json previously included a redundant version field in each entry object. Since all entries in a release share the same version as the top-level manifest version, this duplication was unnecessary. The version field has been removed from individual entries, with the version information now available only at the top level of the JSON payload.
release publish command for more flexible release automation. You can now prevent GitHub from marking a release as latest with --no-latest (useful for backport releases), and automatically commit staged changes before tagging with --commit.
Dec 18, 2025 · @mavam, @claude
The release publish command now supports two new options for smoother release
automation:
--no-latest prevents GitHub from marking the release as latest, useful for
backport releases to older branches--commit commits staged changes before creating the tag, eliminating a
manual step in release workflows. The commit message defaults to
Release {version} but can be customized via --commit-message or the
release.commit_message config option.Dec 17, 2025 · @mavam, @claude
Release notes now include an H1 heading at the top of the document. The heading is derived from the manifest title field:
# Big Release){project_name} {version} (e.g., # Tenzir Changelog v1.0.0)This applies to all release notes generation: notes.md files created during releases, the release notes command output, and markdown exports via show --markdown.