Merge Up

Symfony Branch Cascade Merge

Merges each maintained branch into the next one, from oldest to newest.

Progress checklist

• Step 0: Pre-flight checks
• Step 1: Fetch maintained branches and pull them
• Step 2: Cascade merge loop

Confirmation rule

Whenever the skill says "Wait for confirmation", treat anything other than an explicit affirmative as no: stop and ask the user how they want to proceed.

Step 0 — Pre-flight checks

git status --porcelain --untracked-files=no

If any output, stop:

"The working tree is not clean. Please commit or stash your changes first."

Step 1 — Fetch maintained branches and pull them

1a. Get the branch list

curl -s https://symfony.com/releases.json

Read maintained_versions. It is already sorted oldest → newest (e.g. ["6.4", "7.4", "8.0", "8.1"]). Store as BRANCHES.

1b. Pull every branch

For each branch in BRANCHES:

git checkout <branch>
git pull --ff-only origin <branch>

Using --ff-only ensures local branches haven't diverged from origin. If the pull fails, stop and report the error.

Step 2 — Cascade merge loop

For each consecutive pair (SOURCE, TARGET) in BRANCHES:

2a. Merge

git checkout <TARGET>
composer up

Read the merge-up notes of the incoming pull requests first. The bot copies the whole pull request description into the merge commit, so the authors' own instructions for this merge are already in the local history, and many descriptions end with a "Merge-up to <branch>" paragraph naming the properties to add, the style the target branch expects, or the resolved code itself:

git log --merges --format=%H <TARGET>..<SOURCE> \
  | xargs -I{} git log -1 --format=%B {} \
  | grep -inE 'merge(d| )?-?up|adapt|on [0-9]+\.[0-9]'

Prefer the resolution a note gives over an equivalent one of your own: it is what the author wrote the change for and usually ran on the target branch already, and a merge commit is the wrong place for a refactor. A note also covers files that merge cleanly, which is why this runs before the merge and not only when git reports a conflict.

git merge <SOURCE>

Three outcomes are possible:

• Already up-to-date: print "✓ <TARGET> already up-to-date with <SOURCE>" and skip to the next pair.
• Clean merge (no conflicts): git creates the merge commit automatically. Proceed directly to step 2c.
• Conflicts: proceed to step 2b.

2b. Resolve conflicts (only when git reports conflicts)

List conflicts:

git diff --name-only --diff-filter=U

Read each conflicted file, resolve it, then git add it. When all are resolved:

git commit --no-edit

Conflict resolution rules

Structural divergence across major versions

A newer major may have removed deprecated classes, attributes, or config formats (e.g. TaggedLocator, XML DI config), raised the minimum PHP version, or refactored shared logic into a trait or a new utility class. When merging across such a boundary:

• Remove test methods marked @group legacy / #[Group('legacy')] for deprecations the new major dropped, and any test/fixture/import that references a removed symbol (otherwise it fatals on the TARGET).
• Each major raises the minimum PHP (min PHP per branch in releases.json min_php_requirements: 6.4=8.1, 7.4=8.2, 8.0=8.4). Code merged from SOURCE that branches on or polyfills a PHP below the TARGET's minimum (\PHP_VERSION_ID < ... guards, or function_exists() / class_exists() fallbacks for now-always-available symbols) is dead on the TARGET and can be collapsed to the modern path. The TARGET usually dropped it already, so prefer its version; clean up only where SOURCE's old-PHP code lands somewhere the TARGET had not simplified.
• Prefer the TARGET branch's approach for any refactored idiom.
• Fastest sanity check: look at how the downstream branch (one already past this divergence, e.g. 8.2 while resolving on 8.0) resolved the same files, and match it.

Divergence a clean merge hides

Most of these produce no conflict at all: the merge succeeds and the tests fail. All three show up as a merged test that is fine on SOURCE and wrong on TARGET.

• A config key the TARGET removed or deprecated. A merged test builds a config array ('annotations' => false, 'profiler' => ['collect_serializer_data' => true]) that the TARGET no longer accepts. The symptom is Unrecognized option "x" under "framework" with the valid list attached, or a deprecation the run reports as an issue. Drop the key: these are boilerplate, not what the test is about. Grep the whole merge diff for the key, since several merged tests usually carry it.
• Registration the TARGET gates. The TARGET may drop a service unless something consumes it (profiler or test mode, for instance), so a merged test asserting on it fails with "You have requested a non-existent service". Do not assert on a stripped container: rebuild it the way the TARGET's own sibling tests do, keeping the assertion intact.
• A default the TARGET flipped. SOURCE adds a code path behind a flag whose default the TARGET changed, so the new path becomes the TARGET's default and changes observable output. Both sides merge cleanly and the assertions SOURCE wrote for the old path now fail. Confirm with git log <TARGET> -S'<flag> = <value>', then adapt the expectations, capturing the real output from a run rather than guessing at it.

After resolving, show git diff HEAD~1 (first parent of the merge commit, i.e. the previous TARGET state) and wait for the user to confirm the resolution looks correct before proceeding.

2c. Run tests for affected components

Extract component, bridge, and bundle names from changed files:

git diff --name-only HEAD~1..HEAD

Paths look like src/Symfony/{Component,Bridge,Bundle}/<NAME>/.... Deduplicate, then run tests for each:

./phpunit src/Symfony/Component/<NAME>
./phpunit src/Symfony/Bridge/<NAME>
./phpunit src/Symfony/Bundle/<NAME>

For files under src/Symfony/Contracts/, run the single shared test suite:

./phpunit src/Symfony/Contracts

Ignore files outside these directories (root configs, .github/, etc.): they don't have component-level test suites.

Read the whole summary line, not just the exit status: a suite can end with Tests: N, Failures: 1 or abort on a Fatal error well before any FAILURES! banner, and ANSI colour codes sit in front of those words, so a check anchored to the start of a line reports a red run as green.

If tests fail or report PHPUnit deprecations (the PHPUnit version may differ between branches), first check whether the failure is pre-existing. Cheapest test first: if the merge did not touch the failing area, it did not cause the failure.

git diff --name-only HEAD~1..HEAD -- <path of the failing test or the code it covers>

Only when that is inconclusive, run the test on the TARGET before the merge (git checkout HEAD~1, run, git checkout <TARGET>). Beware a CI baseline as evidence: a branch tip that has not been pushed in a while keeps an old green run, and CI installs dependencies fresh on every run, so a release made in between can turn a suite red with no commit to blame.

Only fix failures introduced by the merge:

1. Analyze and fix the code, including any PHPUnit deprecation notices.
2. Commit the fix: [<ComponentName>] Fix merge conflict resolution.
3. Re-run failing tests until green and deprecation-free.

Report any pre-existing failures to the user without attempting to fix them.