[FEA]: Automate generating release notes structured based on required PR labels

[jrhemstad]

Is this a duplicate?

• I confirmed there appear to be no duplicate issues for this request and that I agree to the Code of Conduct

Area

Infrastructure

Is your feature request related to a problem? Please describe.

As a user and consumer of CCCL, I would like CCCL's release notes to be structured to help me find updates that are relevant to me.

I would like to make it part of CCCL's release automation to auto-generate structured release notes based on labels required to be applied to PRs before they can be merged.

For example, in RAPIDS repos their release notes are auto-generated in the following structure:

# Breaking Changes
// all PRs with the "breaking" label

# Bug Fixes
// all PRs with the "bug-fix" label

# Documentation
// all PRs with the "doc" label

# New Features
// All PRs with "non-breaking" label

Furthermore, part of their CI status check requires one of these labels be set in order to merge. This prevents accidentally merging a PR without one of these required labels and ensuring our release notes are comprehensive.

In RAPIDS they had to implement this logic themselves, but it looks like this functionality is built directly into GitHub now which should make it even easier.

As far as I can tell, the built-in functionality only solves generating the release notes based on labels. It doesn't do anything to require PRs have a label to be merged. So we'd still need to add that as our own workflow for the CI status check.

RAPIDS implementation of the label checker is unique to the fact that they don't use GitHub's native UI for merging PRs and instead uses a bot with triggered by a /merge command. Triggering the merge command will check for the required labels and fail if not present.

I had been thinking of instead implementing this as a workflow and making it required for the status check.

Describe the solution you'd like

• Determine desired structure of generated release notes and required labels
• Implement label checker as part of CI status check
• Implement .github/release.yml file for auto-structured release notes

Describe alternatives you've considered

No response

Additional context

No response

[gevtushenko]

It might be helpful to split release notes into functionality domains.
We should compare different options, here's one of them:

C++

Parallel Algorithms

New Features

Breaking Changes

Documentation

Bug Fixes

Cooperative Algorithms

...

Vocabulary Types

...

Python

Parallel Algorithms

...

Cooperative Algorithms

...

Vocabulary Types

...

The exact partitioning will likely depend on @gonidelis work on #2841.