Description

Currently when facilitating a release of the Plugin, the release lead must manually assign each PR to "feature" and then organise into those features.

This is not a good task for humans as it takes a lot of time. This puts an undue burden on the release lead.

This PR attempts to automated this process. It does this by:

• Taking each PR in a section (eg: Experiments, Bug fixes...etc).
• Determining the most appropriate "feature" for that PR.
• Sorting by most PRs in the feature.
• Printing out each feature along with PRs in a nested list structure (as has been common in the most recent releases).

The heuristic to determine the "feature" is very basic:

• If the PR has a [Feature] label then use that feature name.
• If the PR has a [Block] XXX label then use Block Library as the feature name.
• Otherwise use an arbitrary map of labels to "feature" to determine the most appropriate feature based on the number of occurrences of the particular feature label.

Obviously the hardcoded map of labels => features is far from complete but that's simple enough and can be augmented over time. The goal of this PR is a stepping stone towards the optimal solution.

This is part of addressing #30538

How has this been tested?

• Check out PR.
• In terminal in root of Gutenberg directory run npm run changelog.
• Terminal will output the changelog.
• You should see it organised into groups along the lines of https://github.com/WordPress/gutenberg/releases/tag/v11.0.0-rc.1.
• You should see Unknown as the last feature group in each seciton.

If you want you can target a particular milestone using the format:

npm run changelog -- --milestone="Gutenberg 11.0"

Github has rate limits on the API so I suggest grabbing your Github developer token from https://github.com/settings/tokens and passing that in the --token arg:

npm run changelog -- --milestone="Gutenberg 11.0" --token=YOUR_TOKEN

Screenshots

Types of changes

New feature (non-breaking change which adds functionality)

Checklist:

• My code is tested.
• My code follows the WordPress code style.
• My code follows the accessibility standards.
• I've tested my changes with keyboard and screen readers.
• My code has proper inline documentation.
• I've included developer documentation if appropriate.
• I've updated all React Native files affected by any refactorings/renamings in this PR (please manually search all *.native.js files for terms that need renaming or removal).