Changelog script: More fine-grained Changelogs for patch releases #28424
Conversation
|
Size Change: +219 B (0%) Total Size: 1.38 MB
ℹ️ View Unchanged
|
ockham
force-pushed
the
update/changelog-generator-granular-patch-releases
branch
from
98190a3 to
edb52d9
Compare
Can we instead check the "close date", is is something that is not available on the PR? |
It's not available on the issues list endpoint (which only has the more general We might however iterate over that list, and get each individual issue from it, and then filter those issues by their |
Ah, we might even have the |
|
Tests are failing because of octokit/plugin-rest-endpoint-methods.js#64 🙄 |
Found a workaround: https://docs.joshuatz.com/cheatsheets/js/jsdoc/#advanced-casting |
|
Should be ready for another look 🙂 |
|
I tried this and it seems to work decently but it breaks a use-case for this script. Right now, sometimes we only generate the changelog after the tag/release happens (because of time) or something else. In other words, it's impossible with this PR to regenerate the changelog of old milestones. We used to do that by just doing Right now the meaning of that command is different, instead of getting the changelog for 9.9.0, we get the changelog for potential unreleased commits on that branch. It seems we might need both behaviors: Alternatively, we could change the "milestone" argument and use a "version" argument instead but I supposed this would be harder to implement. |
|
Right 🤔 Well I'm planning to use the changelog script to prefill release notes (and update the Changelog based on those), so ideally we won't need to invoke the script manually anymore. However, I realize that it makes sense to retain this option for later; and furthermore, I just realized that the I'll play with this. Looks like I'll need to change the API of a function or two 😬 |
|
I've added an |
|
When you run the command on a branch that is released fully (like 9.9), you get this error. it's a decent error but maybe we should clarify that it's about "unreleased commits". Other than that, it's working great.
|
Good point! Addressed in d9e7e97. |
ockham
deleted the
update/changelog-generator-granular-patch-releases
branch
Description
The Changelog generator script,
bin/plugin/commands/changelog.js, currently doesn't support patch releases: It's only possible to generate a Changelog for a given milestone (which are per-minor-release, i.e. per-release-branch), but not on a more fine-grained basis. If the Changelog script is run for a patch release, the generated Changelog includes everything from the.0stable release from that series up to the patch release.This PR adds an
--unreleasedoption to the Changelog script that makes it look up the latest release in the series, and only includes issues that were modified after that release was published. This will allow us to use the script to generate the Changelog for patch releases (or at least a baseline -- see 'Discussion' for a caveat).This will come in handy as we automate more and more parts of the build process -- especially to auto-generate a Changelog for patch releases, and to pre-populate the corresponding release notes. (Cf. #28138.)
How has this been tested?
Apply this patch to simulate that you're creating the Changelog for v9.8.1, and that the latest release is v9.8.0:
Then, run:
Output
Before:
Basically like the 9.8.0 changelog, plus the PRs on the 9.8 milestone that have been merged since 9.8.
After:
Only issues that have been modified since 9.8.0 was published:
Discussion
Note that this still includes a few erroneous entries (e.g. the
srcsetissue under theVariousheading). The reason for these is that we use thesinceparameter to filter for issues that have been modified since the previous release in the series was published. However, that doesn't just include closed issues, but also issues to which a new comment was added, or that were otherwise modified.I do think however that it's better to (manually) go through a few stray extra Changelog entries rather than getting the entire Changelog for the
.0version of the series again.Possible future improvements
In a future iteration, I think we should maybe reconsider our source of truth for Changelog generation: Maybe we shouldn't query the list of issues/PRs for the milestone from the GitHub API. Instead, we have more reliable information right at our fingertips: git itself. We might just want to call
git logwith some arguments to get that exact kind of information (in a more reliable way than from GH's milestone, which just manually replicates that information). If we still want/need PR numbers etc, we can probably query those from the GH API, based on the Changelog obtained fromgit.