-
Notifications
You must be signed in to change notification settings - Fork 4.3k
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
Improve changelog generation #27744
Improve changelog generation #27744
Conversation
Size Change: 0 B Total Size: 1.28 MB ℹ️ View Unchanged
|
I don't think we need an accessibility category in the changelog but we can use this to group items inside "bugs" or "enhancements".
Sometimes something is both experimental and a bug fix (or enhancement), I believe we should give priority to "Experimental" in this case. Does the tool do that?
These should be subsections of the "Experimental" section, is this the case? Same for screen navigation and widgets
This doesn't mean anything for me in terms of changelog and I believe we should remove it.
These should be removed from the changelog entirely, mobile apps have their own process for releases. Thanks for your work here. |
Accessibility, Experimental, and Breaking Change now work as you suggested. In case you want to take a look and suggest other changes, this is how the categorization mechanism works: if a PR has many labels, the one that has a lower index in the "FSE: ..." and "Screen: ...". With the current setup, it's straightforward to make these sub-headings within the experimental section (add one Mobile. Now that they are grouped within a category, deleting them is straightforward. I didn't remove it in case the release manager wants to double check them. Thoughts? Good to go and iterate? |
I think in the previous release changelogs, we did group these in experiments but manually. It would be good if we can stay consistent.
I believe the previous version of the changelog command did remove these. -- I'll give this a try in a few minutes. |
Just gave this a test and here's what I don't like:
It seems there's an opportunity to do better in terms of grouping based on "blocks" and things like that but that's something for later. |
5e968ff
to
27eca61
Compare
@youknowriad addressed your suggestions, so as it is, it should reduce the amount of time required to re-categorize issues. |
'[Block] Post Featured Image': 'Experiments', | ||
'[Block] Post Hierarchical Terms': 'Experiments', | ||
'[Block] Post Title': 'Experiments', | ||
'[Block] Site Logo': 'Experiments', |
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.
Just tested the PR and it works great. as a follow-up we might want to group more things automatically for instance, create a sublist for all FSE related block PRs
``
Experiments:
- Full Site Editing Blocks:
- entry 1
- entry 2
There are more things that could use this "sub grouping".
Part of #27448
This PR tries to improve the changelog generated for each release, so it needs less manual intervention. These are the sections the changelog would produce with this PR's changes:
What I've done
How to test
./bin/commander.js changelog
and review what the 9.7 would look like../bin/commander.js changelog -m "Gutenberg 9.6"
and compare with the release post for 9.6. Does it feel like a good match?./bin/commander.js changelog -m "Gutenberg 9.5"
and compare with the release post for 9.5. Does it feel like a good match?./bin/commander.js changelog -m "Gutenberg 9.4"
and compare with the release post for 9.4. Does it feel like a good match?Next steps
The next step I'd like to address is the ability to group PRs within the same section. For example, group all PRs that affect the same block in the "bug fixes" section, or perhaps convert "FSE: ...", "Screen: ..." sections to groups within the "Experiments" category, etc.
I'd like to address this separately but the changes here should already be useful in reducing the amount of time involved in preparing the release post.