Skip to content

Explain known-range notes removed while the range keeps an end - #4

Merged
zuhairhalawa merged 1 commit into
mainfrom
checks/known-range-note
Nov 5, 2026
Merged

zuhairhalawa merged 1 commit into
mainfrom
checks/known-range-note

Conversation

@zuhairhalawa

@zuhairhalawa zuhairhalawa commented Nov 5, 2026 •

Copy link
Copy Markdown
Owner

Gives a removed last_known_affected_version_range an accurate explanation when the ranges still have an end. There is no new command or option, no version bump and no release in this PR.

What changes

Edit Before Now
Note removed, ranges still have an end field-removed, saying the value "may have been dropped by accident" known-range-removed, saying whether the end also changed
Note removed, no end left field-removed field-removed, unchanged, because that really can lose data
Note replaced by a range's one new end known-range-converted known-range-converted, unchanged

Both cases are review, so this does not change any exit code without an allow list. Any other key dropped from database_specific is still reported as field-removed.

Behaviour change to check

--allow field-removed no longer covers a note removed while an end remains. Use known-range-removed. In exchange, allowing it does not also allow other removed fields.

Why it still needs review

Across 96 public advisory edits:

Count
Notes removed while an end remains 40
End also changed 27
End stayed the same 13
Of those 13, the note names exactly the same end 0

Some notes differ only by the next release, such as <= 8.6.0 with fixed 8.6.1. Others differ a lot, such as < 8.0.0 with fixed 8.6.40. Telling them apart needs version comparison, which the tool does not do, so passing these silently could hide a real difference.

How it was checked

Locally, on Windows with Node 24.16.0: typecheck, lint, build, 519 tests (508 existing plus 11 new), verify:pack 46 of 46, verify:schema, and npm audit with no vulnerabilities.

Existing tests changed. Three tests in test/real-edits.test.ts from the previous change now expect known-range-removed, because those edits keep an end.

Deliberate breaks. The new code was broken in 10 ways in a throwaway copy, and the tests caught all 10.

Real edits. Compared with main on 202 edits: 106 advisory PRs of mine and 96 public edits, including 38 from older commits not used for this design. No exit code changed, no other finding changed and nothing crashed.

Limits

  • This improves the explanation and does not reduce the number of stops. The note was the only thing needing review in 9 of the 96 public edits, and those still exit 1.
  • "Same end" compares the end events before and after the edit. It says nothing about whether the note agreed with them.
  • No outside review.

Removing last_known_affected_version_range while the ranges still have an end
was reported as field-removed, which suggested the value may have been dropped
by accident. In real edits the end had usually moved too.

known-range-removed still needs review, and says whether the end also changed.
With no end left it stays field-removed, because that really can lose data.

--allow field-removed no longer covers this case. The version is not bumped.
@zuhairhalawa
zuhairhalawa merged commit 33fe417 into main Nov 5, 2026
11 checks passed
@zuhairhalawa zuhairhalawa mentioned this pull request Nov 5, 2026
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

1 participant