Release

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

Convert the current development SNAPSHOT into a final release: cut a release_x.y.z branch off develop, update every place that names the current release/snapshot 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: the version number itself, every file that echoes it (pom.xml, README.md, docs/antora.yml, Antora pages with dependency snippets), the human-readable release notes (whats-new.adoc and CHANGELOG.md), and the pull request 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

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 SNAPSHOT with the suffix stripped, a patch bump on the latest tag, or a major bump on the latest tag — plus a free-text "Other" option.

Current SNAPSHOT with -SNAPSHOT stripped (e.g. 1.4.0-SNAPSHOT → 1.4.0).

Upcoming SNAPSHOT version

Yes (asked interactively)

The next development version, chosen via AskUserQuestion from three bump candidates (minor/patch/major) computed from the release version just chosen. Used only for human-readable "latest snapshot" mentions in README/docs — it is not written into pom.xml.

Minor bump on the release version, -SNAPSHOT appended (e.g. release 1.4.0 → next 1.5.0-SNAPSHOT).

Outputs

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

  • pom.xml updated to the release version; README.md, docs/antora.yml, and any Antora page with a dependency snippet updated to show the release version as "latest release" and the upcoming SNAPSHOT as "latest snapshot".

  • 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 titled Release <version>, carrying a iru-release label and a description filled in from the actual diff.

  • A final report naming the versions chosen, the branch/PR, the files touched, and a reminder that merging and publishing the release triggers the Sync workflow’s automatic snapshot bump back into develop.

  • 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["Gather state: pom.xml SNAPSHOT version,\nlatest tag, clean working tree, main/master base branch"] C --> D[Ask user for the release version] D --> E[Ask user for the upcoming SNAPSHOT version] E --> F[Create release_x.y.z branch off develop] F --> G["Update pom.xml, README.md (via setup-readme\nor by hand), docs/antora.yml, and Antora\npages with version snippets"] 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["Push branch; open PR against\nmain/master with release label"] K --> L[Invoke pr-description skill\nto fill in the PR body] L --> M[Report versions, branch, PR URL,\nfiles updated, sync-workflow reminder]

Dependencies

Invokes

  • Setup Readme — Step 7, to refresh README.md’s version references (latest release / latest snapshot) once `pom.xml already carries the new release version. If iru-setup-readme isn’t available in the repository, iru-release falls back to updating those same mentions in README.md by hand instead.

  • PR Description — Step 14, 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 13.

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 10), 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 10, 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.