Repository navigation
Explain known-range notes removed while the range keeps an end - #4
Merged
Merged
Conversation
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.
Merged
This file contains hidden or 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
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.
Gives a removed
last_known_affected_version_rangean 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
field-removed, saying the value "may have been dropped by accident"known-range-removed, saying whether the end also changedfield-removedfield-removed, unchanged, because that really can lose dataknown-range-convertedknown-range-converted, unchangedBoth cases are
review, so this does not change any exit code without an allow list. Any other key dropped fromdatabase_specificis still reported asfield-removed.Behaviour change to check
--allow field-removedno longer covers a note removed while an end remains. Useknown-range-removed. In exchange, allowing it does not also allow other removed fields.Why it still needs review
Across 96 public advisory edits:
Some notes differ only by the next release, such as
<= 8.6.0withfixed 8.6.1. Others differ a lot, such as< 8.0.0withfixed 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:pack46 of 46,verify:schema, andnpm auditwith no vulnerabilities.Existing tests changed. Three tests in
test/real-edits.test.tsfrom the previous change now expectknown-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
mainon 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