Changelog as evidence for a version window
Changelog research starts with an explicit version window: which source version and target version define the changes being studied. Read official release notes, migration guides, or changelog sections for every relevant transition rather than relying on the name of the new version.
The goal is not to rewrite the entire changelog, but to extract changes that could affect the affected code, configuration, runtime, build, integrations, or operations.
Classifying discovered changes
| Change type | What to check in the repository | Recording result |
|---|---|---|
| Breaking API | imports, calls, signatures, adapters | affected symbol and focused check |
| Deprecation/removal | usage, configuration, replacement path | version + official section + action |
| Behavior change | outputs, errors, ordering, retries | representative scenario and contract impact |
| Configuration/runtime | env, defaults, startup, deploy | assumption, environment check, owner |
| Unknown | inaccessible or ambiguous source | Unknown + specific next check |
Minimal changelog finding record
## Finding: <version and change>
- Source: <official URL or repository file:section>
- Affected area: <module, API, config, runtime>
- Change type: <breaking | deprecated | behavior | operational>
- Expected impact: <what may change>
- Confidence: <confirmed | needs verification | Unknown>
- Next check: <focused command or scenario>Changelog research sequence
- Record the source version, target version, and search boundaries.
- Collect official release and changelog entries within the version window.
- Filter breaking, deprecated, behavior, configuration, and operational changes.
- Map each change to a specific repository area or mark it as unaffected.
- Add an evidence anchor, confidence, and the next focused verification.
- Stop if the target or relevant release evidence remains unknown.
Canonical lesson source · JavaRush
Open JavaRush material