Summary
The current release-drafting setup groups merged pull requests by labels: breaking-change, feature, enhancement, documentation, bug/fix, deprecation, and internal/dependencies (.github/release-drafter.yml, lines 2–25). It excludes skip-changelog (lines 26–27). The workflow updates the draft after pushes to main and can also be run manually (.github/workflows/release-drafter.yml, lines 15–20), using Release Drafter to create or update the draft (lines 24–32).
As part of the label cleanup accompanying #5618, breaking-change, feature, enhancement, documentation, bug, deprecation, and internal were archived. Archived labels cannot be applied to new pull requests. dependencies and skip-changelog remain active, so release drafts will progressively lose nearly all useful grouping while retaining only dependency grouping and changelog exclusion.
Why is this needed?
Pull request titles are already enforced by organization-level checks to follow Conventional Commits, and the repository template also requires conventional commit semantics (.github/PULL_REQUEST_TEMPLATE.md, lines 13–20). The type, scope, and breaking-change information previously duplicated in labels is therefore already available in each pull request title.
Draft generation should use that source of truth instead of depending on archived labels. This prevents release notes from silently degrading and removes manual label maintenance that no longer fits the repository's issue-type-based workflow.
Which area does this relate to?
Solution
The owner's intent is to replace label-based release-note grouping with grouping derived from Conventional Commits pull request titles, ideally using ship-it-cli, which the owner maintains and which underpins the release tooling.
There is no direct ship-it-cli invocation under .github/workflows/. The closest integration is the make-version workflow delegating version and changelog generation to the shared aws-powertools/actions version-n-changelog action (.github/workflows/make-version.yml, lines 47–53). The implementation should reuse or expose the same tooling as the release workflow rather than introduce a guessed, separate invocation.
A suitable implementation should:
- replace or retire both
.github/release-drafter.yml and .github/workflows/release-drafter.yml in favor of Conventional-Commits-driven draft generation;
- derive release-note categories from pull request title type, scope, and breaking-change markers;
- preserve the current
skip-changelog exclusion behavior;
- continue producing an up-to-date draft release through an appropriate automated and manually runnable workflow; and
- update the Drafting release notes section of
MAINTAINERS.md, which currently tells maintainers that changes are grouped and corrected through labels (MAINTAINERS.md, lines 238–246).
Acknowledgment
Future readers
Please react with 👍 and your use case to help us understand customer demand.
Summary
The current release-drafting setup groups merged pull requests by labels:
breaking-change,feature,enhancement,documentation,bug/fix,deprecation, andinternal/dependencies(.github/release-drafter.yml, lines 2–25). It excludesskip-changelog(lines 26–27). The workflow updates the draft after pushes tomainand can also be run manually (.github/workflows/release-drafter.yml, lines 15–20), using Release Drafter to create or update the draft (lines 24–32).As part of the label cleanup accompanying #5618,
breaking-change,feature,enhancement,documentation,bug,deprecation, andinternalwere archived. Archived labels cannot be applied to new pull requests.dependenciesandskip-changelogremain active, so release drafts will progressively lose nearly all useful grouping while retaining only dependency grouping and changelog exclusion.Why is this needed?
Pull request titles are already enforced by organization-level checks to follow Conventional Commits, and the repository template also requires conventional commit semantics (
.github/PULL_REQUEST_TEMPLATE.md, lines 13–20). The type, scope, and breaking-change information previously duplicated in labels is therefore already available in each pull request title.Draft generation should use that source of truth instead of depending on archived labels. This prevents release notes from silently degrading and removes manual label maintenance that no longer fits the repository's issue-type-based workflow.
Which area does this relate to?
Solution
The owner's intent is to replace label-based release-note grouping with grouping derived from Conventional Commits pull request titles, ideally using ship-it-cli, which the owner maintains and which underpins the release tooling.
There is no direct
ship-it-cliinvocation under.github/workflows/. The closest integration is themake-versionworkflow delegating version and changelog generation to the sharedaws-powertools/actionsversion-n-changelogaction (.github/workflows/make-version.yml, lines 47–53). The implementation should reuse or expose the same tooling as the release workflow rather than introduce a guessed, separate invocation.A suitable implementation should:
.github/release-drafter.ymland.github/workflows/release-drafter.ymlin favor of Conventional-Commits-driven draft generation;skip-changelogexclusion behavior;MAINTAINERS.md, which currently tells maintainers that changes are grouped and corrected through labels (MAINTAINERS.md, lines 238–246).Acknowledgment
Future readers
Please react with 👍 and your use case to help us understand customer demand.