-
Notifications
You must be signed in to change notification settings - Fork 4.2k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Automate grouping of release Changelog
PRs by feature
#33229
Conversation
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I've check recent changelogs for more label mappings and here are a few more direct ones, I would say ordered by precedence:
- 'REST API Interaction': 'REST API'
- '[Package] Icons': 'Icons'
- '[Feature] Design Tools': 'Design Tools'
- '[Feature] Template Editing Mode': 'Template Editor'
- '[Package] Edit Post": 'Post Editor'
These others would have precedence in the mappings:
- '[Feature] Component System': Components
- '[Package] Components: 'Components'
And these others usually are bundled together under "Block Editor" if they don't fit anywhere else (or, if the same label appears a lot in a single release, it might make sense to separate them on their own section in that release):
- '[Feature] Inserter': 'Block Editor'
- '[Package] Rich text': 'Block Editor'
- '[Feature] Drag and Drop': 'Block Editor'
- '[Feature] Block Multi Selection': 'Block Editor'
- '[Feature] Link Editing': 'Block Editor'
This comment has been minimized.
This comment has been minimized.
@gwwar As you are running the Basically it tries to doing some basic sorting and grouping of PRs into "Features" within each section upfront. That should save the release lead time. |
This is the raw changelog for Features
Enhancements
New APIs
Bug Fixes
Experiments
Documentation
Code Quality
Tools
Various
|
@priethor Thanks for the changlog. Is that At this point I guess what we need is to try and improve the list of labels to arbitrary feature groupings. This is easy using Github's "Suggestion" UI in the PR review process. We should be able to flesh this out. The current mechanic for determining a feature for a given PR is:
This means we can manually categorise but still have some basically classification as fallbacks. In the future we can get more sophisticated but for now this moves the needle to make things a little better than they are now. Personally I don't think we need to get everything perfect for this PR to land. Even what we have now is probably better than what we have now in trunk. We can improve incrementally over time. I think perhaps a code review from @gziolo or someone else familiar with the build tooling would be great. |
FYI here's what I currently get for Gutenberg 11.1.0 (upcoming release) when I run the script. I think whilst not perfect it's pretty decent as a starting point for the release lead: Features
Enhancements
New APIs
Bug Fixes
Experiments
Documentation
Code Quality
Tools
Various
|
Co-authored-by: Dave Smith <getdavemail@gmail.com>
a176389
to
9e19907
Compare
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I think that this PR is already a nice improvement as it groups changelog entries nicely. I would love to hear from @priethor about the shape of the changelog, but overall it goes in the direction we discussed.
I left some minor comments to consider, but it could be also done in a follow-up. I'm less concerned about the code because I can follow it and it isn't something that is going to be reused in other places. @getdave, in the places where you consider extracting functions you could also try using named functions and see if that makes it more readable.
That's right, it's 11.1.0-rc.1. Edited and fixed it! |
Changelog
PRs by feature
Changelog
PRs by feature Changelog
PRs by feature
This is cool, saves a lot of time. That said the "uncategorized/unknown" sub title should be removed and its items just moved top-level (without any grouping) if possible. |
The idea is that it is made obvious you need to recategorise these items. Simple enough to do though if we want... |
I don't think all items need to be categorized 🤷♂️ In the last patch release, I just removed it for instance. |
Oh sorry, I've just realised you're referring to the |
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:
Experiments
,Bug fixes
...etc).[Block] Legacy Widget
should end up inWidgets Editor
and not inBlock Library
.The heuristic to determine the "feature" is very basic. Firstly, it prefers to use an arbitrary map of labels to "feature" to determine the most appropriate feature. If no mapping ius found then the following additional attempts at classification:
[Feature]
label then use that feature name.[Block] XXX
label then useBlock Library
as the feature name.Unknown
.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?
npm run changelog
.Unknown
as the last feature group in each seciton.If you want you can target a particular milestone using the format:
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:Screenshots
Types of changes
New feature (non-breaking change which adds functionality)
Checklist:
*.native.js
files for terms that need renaming or removal).