Release v1.5.2

Fixed

• A batched run that skips the release now says why in its log and step summary: it lists the pending pull requests and, while waiting, the oldest merge time and the UTC time the release window elapses, plus how to release now (a manual run with version 0.0.0 or empty). The post step names the reason instead of only saying no release was created. Repositories pick this up through the v1 tag; no workflow change is needed. (#222)

Release v1.5.1

Fixed

• A hotfix waiting alongside a pending major release now fails only the run started by merging the hotfix itself. Scheduled ticks and other merge runs warn and keep the batch pending. (#218)
• Batched release notes now combine the summaries of every pull request into one leading ## Summary, instead of repeating a summary per pull request. (#218)
• Batched releases now warn once for each merged pull request that has no release-intent label. (#218)
• Markdown reference-link definitions in a pull request description are kept when release notes are aggregated. When two pull requests define the same label, the first definition is kept and a warning names the duplicate. (#218)

Release v1.5.0

Added

• Opt-in batched releases: set release-window (minutes) to release everything merged since the last release in one release once the oldest pending merge is older than the window. Notes from the included pull requests are merged by section, the highest release intent wins, and every included (#n) issue is still closed. The default 0 keeps one release per pull request. (part of Cratis/Workflows#189)
• hotfix-labels (default hotfix): a pending pull request with one of these labels releases right away. If a major change is pending, the run started by the merge fails and asks for a manual run; scheduled runs only warn and keep the batch pending. A manual run with no version releases everything pending. (part of Cratis/Workflows#189)
• pull-requests output listing the pull requests a batched release included, and the reasons batched and nothing-pending for runs that release nothing yet. (part of Cratis/Workflows#189)

Release v1.4.3

Fixed

• When GitHub refuses to create the release with 403 because the release commit's .github/workflows differ from the default branch (another pull request changed workflows while this release was pending), the action now fails with an error that names that cause and the recovery: run the publish workflow with workflow_dispatch from the current default branch with the pull request's release notes instead of re-running. Other 403s keep their original error. (#215)

Release v1.4.2

Changed

• HTML comments (<!-- ... -->) are removed from the release notes before the release is created, so pull request template guidance left in a description is no longer published in the release body. Comments shown inside fenced or inline code are kept, and notes holding nothing but a comment count as empty, so GitHub generates them (#195)
• Issues are closed from the published notes, after comments are removed: a (#n) written only inside an HTML comment no longer closes the issue (#195)

Fixed

• A run that loses the version race to a concurrent run now fails its post step instead of reporting success. When the release for its tag already exists for another commit, the step fails naming that commit, so jobs that need the release job do not publish under a version that belongs to someone else; re-running the run releases it under the next version. See Concurrent runs (#178)

Release v1.4.1

Fixed

• A merged pull request carrying more than one of major, minor, patch and no-release releases nothing and reports the error reason with its labels logged, instead of silently letting no-release or the highest bump win (#200)

Release v1.4.0

Added

• The issues a release's notes say it resolves are closed when the release is created, each with a comment naming the release tag. Only a note bullet ending in (#123) counts; prose mentions and cross-repository references are left alone. Needs issues: write, and is turned off with close-resolved-issues: false

Release v1.3.1

Fixed

• Update shared AI guidance so agents handle routine in-scope work without unnecessary approval questions.

Release v1.3.0

Added

• A configurable no-release-labels input, defaulting to no-release.

Fixed

• Intentional no-release merges now report no-release instead of no-label, so workflows can distinguish suppression from missing version intent.

Release v1.2.0

Summary

Prepares the publish workflows to move to the push trigger, which is what makes releases work for pull requests from forks.

Added

• reason output telling you why the action published nothing, so a workflow can fail on a release that went missing without failing on the ones that are expected.

Changed

• A commit that already has a release no longer publishes a second, higher version when its run is repeated (#103).
• Documented that cancel-in-progress: false is required under the push trigger.