Release

This documentation was generated with the assistance of AI. Please report any inaccuracies.

Convert the current development version into a final release: cut a release_x.y.z branch off develop, update every place that names the current release/pre-release version, draft the "what’s new" notes, and open a pull request. This mirrors the repository’s existing release history (release_1.0.0 … release_1.3.0, each a PR into main) — it follows that gitflow convention rather than inventing its own.

Purpose

iru-release automates the mechanical parts of cutting a release so nothing gets missed or drifts out of sync, and it is ecosystem-agnostic: it detects whether the repository is Java/Kotlin JVM (Maven or Gradle, including Spring Boot and Quarkus), TypeScript/npm (including NestJS and Next.js), React Native (Expo or bare CLI/Metro), Android/Gradle, Kotlin Multiplatform (Android + iOS), Swift/Apple (including macOS desktop apps), .NET (including Windows desktop apps), PHP/Composer (including WordPress and PrestaShop), Python (FastAPI, Django, plain package), Rust/Cargo, or Go modules (command-line tools included — Rust, Go, Swift and .NET CLIs map to their ecosystem’s key), and delegates the actual version-file edit to that ecosystem’s own installed iru-<key>-bump-version skill (iru-java-bump-version, iru-typescript-bump-version, iru-react-native-bump-version, iru-android-bump-version, iru-kmp-bump-version, iru-swift-bump-version, iru-dotnet-bump-version, iru-php-bump-version, iru-python-bump-version, iru-rust-bump-version, iru-go-bump-version) rather than editing build files directly. It still owns every other release step itself: the human-readable release notes (whats-new.adoc and CHANGELOG.md), and the pull request — opened against whichever host the repository actually uses (GitHub, Bitbucket, Azure DevOps, or TFS) — that carries the release branch into main/master. It is strict about gitflow — it refuses to run from anywhere but develop — so the release branch always originates from the same integration branch this repository’s history already shows it does.

Purpose group

Repository Maintenance

Plugin

Shipped by the iru-core plugin of the ai-catalog marketplace (install with /plugin install iru-core@ai-catalog; see Plugins).

Invocation

/iru-release

Inputs

Argument Required Description Default

Release version

Yes (asked interactively)

The version to cut, chosen via AskUserQuestion from three computed candidates — current pre-release value stripped (per the detected ecosystem’s convention), a patch bump on the latest tag, or a major bump on the latest tag — plus a free-text "Other" option.

Current pre-release value with its suffix stripped (e.g. Java/Android/KMP 1.4.0-SNAPSHOT → 1.4.0, npm and React Native 1.4.0-dev.0 → 1.4.0, PHP and .NET 1.4.0-dev → 1.4.0, Python 1.4.0.dev0 → 1.4.0, Rust and Go 1.4.0-dev → 1.4.0 (PEP 440; a VCS-derived version such as hatch-vcs/setuptools-scm is treated as the latest tag, with the release tag itself as the release); for a Swift library, the next semver bump from the latest tag).

Upcoming pre-release version

Yes (asked interactively) — skipped for a Swift library, which has no in-tree pre-release marker

The next development version, chosen via AskUserQuestion from three bump candidates (minor/patch/major) computed from the release version just chosen, per the ecosystem’s own pre-release convention. Used only for human-readable "latest snapshot" mentions in README/docs and for an optional follow-up bump-version call — it is not written into any build file by this step.

Minor bump on the release version, with the ecosystem’s pre-release suffix appended (e.g. Java/Android/KMP release 1.4.0 → next 1.5.0-SNAPSHOT; npm/React Native release 1.4.0 → next 1.4.1-dev.0; Python release 1.4.0 → next 1.5.0.dev0).

Outputs

  • A pushed release_<version> branch, branched from develop.

  • The version file(s) for the detected ecosystem bumped to the release version by the matching iru-<key>-bump-version skill (called with sync-files: yes), which also refreshes README.md, docs/antora.yml, and any Antora page with a dependency snippet to show the release version as "latest release". If no matching bump-version skill is installed, this happens by hand instead and the final report says so.

  • docs/modules/ROOT/pages/whats-new.adoc with a new, newest-first section for the release, and CHANGELOG.md with [Unreleased] renamed to the release’s dated section (Keep a Changelog format) and a fresh empty [Unreleased] above it.

  • A commit on the release branch, and a pull request opened against main/master — using whichever host tooling matches this repository (GitHub, Bitbucket, Azure DevOps, or TFS) — titled Release <version>, carrying a release label/tag where the host supports one, and a description filled in from the actual diff.

  • A final report naming the detected ecosystem and bump-version skill used, the versions chosen, the branch/PR and host, the files touched, and — whenever this repository has a .github/workflows/sync.yml (every iru-setup-<stack>-github-workflows skill generates one, whatever the ecosystem) — a reminder that merging and publishing the release triggers that workflow’s automatic next-development-version bump back into develop; otherwise a plain statement that no such automation ran and the next-dev bump is a manual follow-up.

  • If run from any branch other than develop: no files are touched at all — the skill stops at Step 1.

Execution flow

flowchart TD A["Start /iru-release"] --> B{"Current branch is develop?"} B -- no --> B1["Warn and stop:\nask user to checkout develop and retry"] B -- yes --> C["Detect ecosystem (iru-explore report\nor manifests) and matching\niru-&lt;key&gt;-bump-version skill\n(from the session's available skills,\nplugin-safe);\nread current pre-release version,\nlatest tag, clean tree, main/master base"] C --> D["Ask user for the release version"] D --> E["Ask user for the upcoming pre-release\nversion (skipped for Swift library)"] E --> F["Create release_x.y.z branch off develop"] F --> G["Bump version via matching\niru-&lt;key&gt;-bump-version skill\n(sync-files: yes)"] G --> H["Determine changes since previous tag\n(via change-summarizer agent);\nwrite whats-new.adoc and CHANGELOG.md sections"] H --> I["Show diff summary, then commit"] I --> J{"Confirm push + PR with user"} J -- declines --> J1["Stop without pushing"] J -- confirmed --> K["Detect repository host (GitHub/Bitbucket/\nAzure DevOps/TFS); push branch;\nopen PR against main/master with release label/tag"] K --> L["Invoke iru-pr-description skill\nto fill in the PR body"] L --> M["Report ecosystem, bump-version skill used,\nversions, branch, PR URL, host,\nfiles updated, sync-workflow reminder"]

Dependencies

Invokes

  • Java Bump Version, TypeScript Bump Version, React Native Bump Version, Android Bump Version, KMP Bump Version, Swift Bump Version, .NET Bump Version, PHP Bump Version, Python Bump Version, Rust Bump Version, Go Bump Version — Step 6, whichever one matches the ecosystem detected in Step 2 (Java/Kotlin JVM on Maven or Gradle, TypeScript/npm, React Native — package.json with a react-native/expo dependency, whose bump skill also owns the store-facing version (app.json expo.version for Expo, android/app/build.gradle plus the iOS MARKETING_VERSION for Metro) —, Android/Gradle, Kotlin Multiplatform (a Gradle build applying the multiplatform plugin with iOS targets; reads VERSION_NAME in the root gradle.properties), Swift/Apple (a macos-app too), .NET (windows-app and dotnet, or a .slnx/.sln, Directory.Build.props or .csproj; its bump skill owns Directory.Build.props’ `<Version> plus the four-part MSIX Identity Version in Package.appxmanifest/packaging/AppxManifest.xml), PHP/Composer/WordPress/PrestaShop, Python via pyproject.toml, Rust via Cargo.toml ([package] or [workspace.package] version), or Go via go.mod (the Version literal in internal/version/version.go); command-line tools resolve by their language — cli-tool (swift) uses the Swift bump skill and its Version.swift literal, cli-tool (dotnet) the .NET one). When the React Native or KMP bump skill isn’t installed, detection falls back to typescript / android respectively and the final report warns that the store-facing or iOS MARKETING_VERSION must be updated by hand. The installed candidates are read from the skills available in the session (names matching iru--bump-version, which works for copied skills and for plugin installs where .claude/skills does not exist), corroborated with find .claude/skills -maxdepth 1 -type d -name "iru-*-bump-version" when that directory exists, rather than assumed, and the matching one is invoked with sync-files: yes so it also refreshes README.md/docs/antora.yml/Antora dependency-snippet pages itself — iru-release no longer does that work directly. If no matching skill is installed, iru-release falls back to bumping the version file(s) by hand and says so in the final report.

  • PR Description — Step 11, passing the release PR’s target branch as a base-branch argument so the description is drafted against the branch the PR actually targets, to draft and fill in the release pull request’s description once it has been opened in Step 10.

iru-release does not invoke Setup Changelog even though both skills touch CHANGELOG.md. iru-setup-changelog is a one-time bootstrap for a repository that has no changelog yet; iru-release composes and edits CHANGELOG.md directly itself on every run (Step 7), since by the time a repository is cutting releases the changelog already exists and just needs its [Unreleased] section turned into a dated release entry.

Invoked by

None — iru-release is a top-level entry point, run directly by a person via /iru-release.

Related agents

  • iru-change-summarizer — Step 7, to summarize the commit/diff range since the previous release into user-facing changes for whats-new.adoc/CHANGELOG.md, keeping the raw git log/diff content out of this skill’s own context — the same agent iru-setup-changelog uses, applied here to a single range instead of a fan-out across many past releases.

Source

SKILL.md on GitHub — the file this page was generated from.