Tronador CLI v0.5.5: From Version Awareness to Guarded Delivery Workflows

Release history update (October 20, 2026): v0.5.10 is the latest stable GitHub release. Read what changed since v0.5.5 and the Tronador CLI documentation.

Created: October 4, 2026
Updated: October 20, 2026

tronador-cli v0.5.5 was the latest stable release of the Cloud Ops Works command-line toolkit on October 4, 2026. The releases from v0.2.8 through v0.5.5 turn the version-aware project tooling introduced in v0.2.7 into a broader repository lifecycle: more project types can calculate and write versions, template upgrades understand repository configuration, and release branches and tags can be managed through guarded Git workflows.

The repository and packages are named tronador-cli; release installations provide the tronador executable. The complete source-level history is available in the v0.2.7...v0.5.5 comparison.

For command syntax, configuration, and workflow guidance, use the Tronador CLI documentation.

Release timeline

Repository upgrades now follow configuration

The v0.4 line made repository upgrades aware of the active template generation and the configuration already present in the implementation repository. For current v5.10 layouts, Tronador selects the matching template baseline and merges supported Cloud Ops Works YAML values instead of blindly replacing every configuration file.

That selection is intentionally guarded. Ambiguous template metadata, mixed Blueprint generations, unsafe YAML structures, or an unresolved configuration baseline stop the operation or preserve the local file with a warning, depending on the condition. Custom repository content is not covered by a blanket preservation promise; each managed path follows its documented ownership and merge rule.

Preview the selected upgrade before mutation:

tronador repos available --workdir ../my-service
tronador repos upgrade --workdir ../my-service --dry-run

Git workflows became first-class CLI operations

tronador versions supports GitFlow, GitHub Flow, and trunk-based development through checked-in GitVersion profiles. It can initialize the selected way of work and manage feature, hotfix, release, support, and version-tag operations.

The workflow commands validate branch identity and remote state before publishing or deleting refs. Local hotfix and release finishes use a recovery journal and an atomic, lease-protected push when the remote supports it. Purge operations prove that a branch is merged before deletion. The exact behavior depends on the selected way of work: GitFlow uses develop and supports maintenance branches, while GitHub Flow and trunk-based repositories operate from the primary branch.

# Inspect initialization without changing files or branches.
tronador versions init --githubflow --workdir ../my-service --dry-run

# Inspect a release start as a numbered plan.
tronador versions release start --minor --workdir ../my-service --dry-run

Dry runs do not resolve or download GitVersion or GitHub CLI tools. Operations that need those tools resolve explicit paths, PATH, an existing Tronador cache, and finally an opt-in download controlled by --allow-network.

Version generation covers more repository types

Project version generation now distinguishes the output expected by each ecosystem:

• Java can generate snapshot versions, while v0.5.4 keeps the full GitVersion SemVer in VERSION and applies Maven-compatible formatting only to pom.xml.
• Node and Python can request --plain to write an exact x.y.z value.
• Catalog-managed templates can use project version --generate --yes to create or replace the guarded vX.Y.Z upgrade marker.
• Eligible skills repositories gained the same guarded marker workflow in v0.5.0.

Marker generation validates the repository layout and eligibility marker before writing. It does not create a Git tag, commit, or push.

tronador project version --plain --workdir ../node-service
tronador project version --generate --yes --workdir ../template-repository

Better previews and operator feedback in v0.5.5

The latest release makes successful workflow outcomes explicit and structures --dry-run output as a numbered plan. This is especially useful for branch and release operations where the order of validation, branch creation, merge, tag, push, or pull-request steps matters.

The plan is still a preview of the selected operation. Remote state can change after the preview, so the real command repeats its safety checks before it mutates repository or remote state.

Install or upgrade

The shell and PowerShell installers resolve the latest stable GitHub release when no version is supplied:

# Linux or macOS
curl -fsSL https://raw.githubusercontent.com/cloudopsworks/tronador-cli/master/scripts/install.sh | sh

# Homebrew
brew install cloudopsworks/tap/tronador-cli

# Confirm the installed binary
tronador version

Windows PowerShell:

iwr https://raw.githubusercontent.com/cloudopsworks/tronador-cli/master/scripts/install.ps1 -UseB | iex
tronador version

See the installation guide for pinned versions, native Linux packages, upgrades, and uninstall steps. For the earlier version-preview foundation, read the v0.2.7 release article.