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