Improve changelog generation #27744
Merged
Improve changelog generation #27744
Conversation
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
oandregal
added
the
[Package] Project management automation
4 tasks
|
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. |
oandregal
force-pushed
the
try/improve-changelog-match
branch
from
5e968ff
to
27eca61
Compare
|
@youknowriad addressed your suggestions, so as it is, it should reduce the amount of time required to re-categorize issues. |
youknowriad
reviewed
Dec 30, 2020
| '[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.
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".
youknowriad
approved these changes
Dec 30, 2020
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
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 changelogand 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.