Update Existing Branch

Process

1. Check whether the preview moved forward

Determine whether later dotnet/dotnet codeflow commits landed for the same preview branch or tag since the last run.

If the relevant VMR ref moved forward, regenerate changes.json. If it did not, keep the current file and focus on editorial fixes and comment responses.

Typical signals:

• later commits on dotnet/dotnet for release/<major>.0.1xx-previewN
• a newer release-branch head than the one captured in build-metadata.json
• new source-manifest commits for a component already discussed in the draft

2. Compute a delta from the existing files

If you refreshed changes.json, compare the old and new files by stable id.

Classify changes as:

• added — new shipped items not seen in the last run
• changed — same id, but new evidence, labels, revert state, or reviewer context changes the treatment
• removed or superseded — no longer relevant to the current build story, or later evidence shows the original interpretation was wrong
• unchanged — keep the prior editorial work

Do not treat a refreshed changes.json as permission to restart the whole release from zero.

3. Merge into the existing features.json

When features.json already exists, use it as the editorial baseline and merge the delta into it.

Preserve prior annotations for unchanged entries, including:

• score
• score_reason
• score_breakdown
• breaking_changes
• reverted_by / reverts
• useful human notes or hand-tuned annotations

Only rescore:

• newly added entries
• materially changed entries
• earlier entries that reviewers explicitly questioned or that new evidence disproved

This should feel like a delta merge, not a full rescore.

4. Update markdown in place

Use the current draft as the starting point. Prefer integration over duplication.

Examples:

• add a new GC item into an existing Garbage Collection Performance Improvements section
• extend an existing Unsafe Evolution block instead of creating a second heading
• move a newly demoted item into Bug fixes instead of deleting the story without explanation

Keep the existing structure when it still works. Add a new top-level section only when the delta introduces a genuinely new story.

5. Treat review comments as required inputs

Unresolved PR comments are part of the spec for the next run.

• read them before rewriting anything
• answer factual questions with evidence from changes.json, VMR refs, API verification, or the final build
• update the markdown when the reviewer is right
• if the reviewer is directionally right but the current build still contains the feature, explain the milestone and branch context clearly

6. Default outcome

For an existing release-notes branch, the normal loop is:

1. refresh changes.json only if the preview moved forward
2. merge the delta into features.json
3. update the existing markdown in place
4. respond to comments and questions
5. push a follow-up commit to the same PR

This keeps the branch stable for reviewers and avoids throwing away already curated editorial work.