DOC: backfill the Unreleased changelog entries the automation missed

[ting-hong-shieh]

Part of #1173.

What this does

CHANGELOG.md was last touched by 5eae273b on 12 August and the highest pull request it records is #1140. Thirty-nine commits have landed on develop since, so [Unreleased] no longer describes the branch. #1173 notes that those entries will not appear on their own and suggests writing them in one pass from the merge list; this is that pass.

Thirty-two entries, CHANGELOG.md only:

Section	Count
Added	6 ENH, 2 DOC
Changed	1 ENH, 3 CI, 1 MNT, 1 DOC
Fixed	16 BUG, 2 DOC

How they were chosen

From git log 5eae273b..develop, following the rules in the file's own header comment: Added for new features, Changed for changes in existing functionality, Fixed for bug fixes, and tests left out. Seven TST: commits fall in the gap and are therefore not listed, which matches the file's history — TST: appears twice in the whole changelog, against 117 ENH:, 75 BUG:, 42 DOC: and 39 MNT:.

Each entry uses the pull request title and link, as the header comment asks, with the issue linked alongside where the commit names one. 772480d is a direct commit to develop with no pull request, so that entry links the commit.

Newest on top within each section, as the [Unreleased] comment asks.

Verification

Every link was resolved against the API rather than assembled by hand:

45 pull links, 20 issue links (17 distinct issues)
mismatched label vs url: none

Every pull/N link resolves to a pull request, every issues/N link resolves to an issue and not to a pull request, and each entry's text was checked against the pull request's own title. That check caught one wrong description — #1142 is "Document angle-of-attack drag inputs", not the multivariable inputs its squash-commit subject suggests — and twelve smaller drifts from the titles, all corrected.

What this does not do

It does not fix the automation, and the next merge will fall out of the file again. Both causes #1173 identifies are outside what a pull request into develop can reach:

• a pull_request_target workflow is read from the default branch, and master still carries the older changelog.yml with the pull_request trigger, so neither trigger matches anything: pull_request events read the file from the pull request's branch, where only pull_request_target is declared, and pull_request_target events read it from master, where only pull_request is declared;
• RELEASE_TOKEN was already resolving to empty before that, which is why the four runs before CI: run the changelog job for pull requests from forks #1112 all died on actions/checkout.

I confirmed the first against upstream/master:.github/workflows/changelog.yml and the run history; the second needs someone with access to the repository secrets.

[thc1006]

Two numbers in the PR description look stale:

• Added contains 6 ENH entries and 2 DOC entries, not 7 ENH and 2 DOC.
• At this head, [Unreleased] contains 45 pull links and 20 issue links, not 17 issue links.

The total of 32 new entries and the “no mismatched label vs URL” result are both correct.

[thc1006]

One policy point before this lands: the changelog header says tests and GitHub maintenance should not be listed, but this backfill excludes TST commits while including #1112, #1123, #1162 and #1163. The updater script also currently inserts CI, TST and MNT entries, so the repository has two conflicting rules.

Which rule should this backfill follow?

Also, because #1173 is still unfixed, could this branch be refreshed immediately before merge? Otherwise #1177 and any other PR merged after 4263fa9 will begin the next gap straight away.

[ting-hong-shieh]

Both numbers were wrong. Corrected in the description.

• Added gets 6 ENH and 2 DOC. The seventh ENH is ENH: compute rocket static margin lazily (#780) #1135, which went to Changed, and I counted it in both rows. The section totals are 8 / 6 / 18, which is the 32 I claimed.
• 45 pull links and 20 issue links. My check deduplicated before counting and I reported the distinct total as the raw one; Free form fin in the stochastic method #953 alone appears three times. It now reads "45 pull links, 20 issue links (17 distinct issues)".

Thanks — the second one means my verification was reporting a number I had not actually looked at.

Which rule the backfill should follow

There are three, not two, and they disagree in different directions:

1. The header comment in CHANGELOG.md — no tests, no GitHub maintenance, no merge commits.
2. .github/scripts/update_changelog.py — fallback_section_and_prefix maps tests/TST to ### Changed, MNT to ### Changed, and falls through to CI in ### Changed. There is no skip path; every merged pull request gets an entry.
3. What the file actually contains — 117 ENH:, 75 BUG:, 42 DOC:, 39 MNT:, 4 CI:, 2 TST:.

I followed (3), which is why MNT and CI are in and TST is out. That was the wrong thing to follow, because it describes the past rather than what happens next.

The backfill should match (2). Whatever the script does is what every future entry will look like once #1173 is fixed, and if the two disagree then this 32-entry stretch becomes the only part of [Unreleased] with no TST lines — a gap that reads like an oversight rather than a rule. On that basis I should add the seven TST commits from the gap, in ### Changed, which takes the backfill to 39.

The alternative is to make (1) win and give the script a skip path for tests and github maintenance. That is a real design choice — CI: and MNT: entries are arguably both "GitHub maintenance", and dropping them would remove things like #1108's dependency floors that users can be affected by. It also changes 39 existing MNT: entries from correct to accidental.

It is your call which one is the rule. Say which and I will regenerate the backfill to match, and open the script change separately if it needs one.

Refreshing before merge

Agreed, and it costs nothing to do. develop is still at 4263fa9 right now, so this branch is current as of this comment. I will rebase and add whatever has landed immediately before you merge — ping me and I will refresh within the hour.

Unrelated, while we are here

The two TST: entries in the file are #914 in v1.12.0 and #862 in v1.11.0, and #862 is "remove remaining files after test session". That is the same class of problem as the three stray files you caught on #1177: monte_carlo_calisto uses filename="monte_carlo_test", so a test run drops monte_carlo_test.{inputs,outputs,errors}.txt in the repository root and .gitignore does not cover them. Happy to open that as a small separate pull request if it is wanted.

[thc1006]

Thx, this makes the conflict clear. My preference is to make the CHANGELOG header the source of truth rather than adding the seven TST entries because the current updater happens to lack a skip path.